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Abstract 


We describe the design and implementation of GNU Taler, an electronic payment system based 
on an extension of Chaumian online e-cash with efficient change. In addition to anonymity for 
customers, it provides the novel notion of income transparency, which guarantees that merchants 
can reliably receive a payment from an untrusted payer only when their income from the payment 
is visible to tax authorities. 

Income transparency is achieved by the introduction of a refresh protocol, which gives anony- 
mous change for a partially spent coin without introducing a tax evasion loophole. In addition to 
income transparency, the refresh protocol can be used to implement Camenisch-style atomic swaps, 
and to preserve anonymity in the presence of protocol aborts and crash faults with data loss by 
participants. 

Furthermore, we show the provable security of our income-transparent anonymous e-cash, 
which, in addition to the usual anonymity and unforgeability properties of e-cash, also formally 
models conservation of funds and income transparency. 

Our implementation of GNU Taler is usable by non-expert users and integrates with the 
modern Web architecture. Our payment platform addresses a range of practical issues, such as 
tipping customers, providing refunds, integrating with banks and know-your-customer (KYC) 
checks, as well as Web platform security and reliability requirements. On a single machine, we 
achieve transaction rates that rival those of global, commercial credit card processors. We increase 
the robustness of the exchange—the component that keeps bank money in escrow in exchange 
for e-cash—by adding an auditor component, which verifies the correct operation of the system 
and allows to detect a compromise or misbehavior of the exchange early. 

Just like bank accounts have reason to exist besides bank notes, e-cash only serves as part of a 
whole payment system stack. Distributed ledgers have recently gained immense popularity as 
potential replacement for parts of the traditional financial industry. While cryptocurrencies based 
on proof-of-work such as Bitcoin have yet to scale to be useful as a replacement for established 
payment systems, other more efficient systems based on blockchains with more classical consensus 
algorithms might still have promising applications in the financial industry. 

We design, implement and analyze the performance of Byzantine Set Union Consensus (BSC), 
a Byzantine consensus protocol that agrees on a (super-)set of elements at once, instead of 
sequentially agreeing on the individual elements of a set. While BSC is interesting in itself, it can 
also be used as a building block for permissioned blockchains, where—just like in Nakamoto-style 
consensus—whole blocks of transactions are agreed upon at once, increasing the transaction rate. 
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Chapter 1 


Introduction 


New networking and cryptographic protocols can substantially improve electronic online payment 
systems. This book is about the design, implementation and security analysis of GNU Taleı/'] a 
privacy-friendly payment system that is designed to be practical for usage as an online (micro- 
)payment method, and at the same time socially and ethically responsible. 

Payment systems can generally be divided into two types: Register-based and value-based [Rik:7]. 
A register-based system associates value with identities (e.g., bank account balances with cus- 
tomers), while a value-based system associates value with typically anonymous, digital or physical 
tokens (such as cash or prepaid credit cards). In practice, these two types of systems are combined, 
as different layers have different (and often conflicting) requirements: the payment system used 
to pay for a cappuccino in a coffee shop is most likely not suitable to buy real estate. Value-based 
payment systems typically provide more anonymity and convenience but also more risk to 
consumers (as they are responsible to secure the values they hold), while register-based systems 
shift risks to the payment service provider who has to authenticate consumers and ensure the 
integrity of the register. 

This book explains GNU Taler, a design and implementation of a value-based payment system, 
discussing in-depth how to create a practical, privacy-preserving and secure (micro-)payment 
protocol that integrates nicely with the modern web. Our value-based payment protocol can in 
principle operate on top of any existing register-based system. 

GNU Taler is an official package of the GNU projecf?] Our free software implementation is 
freely available from the GNU mirrors. 


11 Design Goals for GNU Taler 


The design of payment systems shapes economies and societies [ZSI13 . Payment systems 
with high transaction costs create an economic burden. Predominantly cash-based societies 


provide some degree of anonymity for their citizens, but can fail to provide a sound foundation 
for taxation, facilitate corruption and thus risk creating weak governments. On the other 
hand, systems with too much surveillance eliminate personal freedom. 

As the Internet has no standardized payment system, especially not one that is capable 
of quickly, efficiently and securely settling small transactions (so-called micropayments), the 
majority of content on the web is financed by advertisements. As a result, advertising (and by 
implication, collecting data on users) has been a dominant business model on the Internet. This 
has not only resulted in a loss of independence of publishers—who need to cater to the needs 
of advertisers—but also in a situation where micro-targeted ads are so wide-spread, that they 
have been suspected to have influenced multiple major elections [Per17]. Ads are also a vector 


thttps://taler.net/ 


“https://gnu.org 
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for malware [Pro+07]. Due to the prevalence of ad blockers, ads are also not guaranteed to be a 
sustainable business model. 

In the world of online payments, credit cards and a sprawling number of smaller, proprietary 
payment processors are currently dominant, and market shares vary widely between different 
countries [Ady16}/LMS16]. The resulting fragmentation again increases social costs: online shops 
can either choose to invest in implementing many proprietary protocols, or only implement 
the most popular ones, thereby reinforcing the dominance of a handful of proprietary payment 
systems. 

Considering these and other social implications of payment systems, we started the devel- 
opment of GNU Taler with a set of high-level design goals that fit our social agenda. They are 
ranked by the importance we give to them, and when a trade-off must be made, the one that 
supports the more highly ranked goal is preferred: 


1. GNU Taler must be implemented as free software. 


Free refers to “free as in free speech”, as opposed to “free as in free beer”. More specifically, 
the four essential freedoms of free software must be respected, namely users must 
have the freedom to (1) run the software, (2) study and modify it, (3) redistribute copies, 
and (4) distribute copies of the modified version. 


For merchants this prevents vendor lock-in, as another payment provider can take over, 
should the current one provide inadequate quality of service. As the software of the 
payment provider itself is free, smaller or disadvantaged countries or organizations can run 
the payment system without being controlled by a foreign company. Customers benefit 
from this freedom, as the wallet software can be made to run on a variety of platforms, 
and user-hostile features such as tracking or telemetry could easily be removed from wallet 
software. 


This rules out the mandatory usage of specialized hardware such as smart cards or other 
hardware security modules, as the software they run cannot be modified by the user. 
These components can, however, be voluntarily used by merchants, customers or payment 
processors to increase their operational security. 


2. GNU Taler must protect the privacy of buyers. 


Privacy should be guaranteed via technical measures, as opposed to mere policies. Especially 
with micropayments for online content, a disproportionate amount of rather private data 
about buyers would be revealed, if the payment system does not have privacy protections. 


In legislations with data protection regulations (such as the recently introduced GDPR in 
Europe [VV17), merchants benefit from this as well, as no data breach of customers can 
happen if this information is, by design, not collected in the first place. Obviously some 
private data, such as the shipping address for a physical delivery, must still be collected 
according to business needs. 


The security of the payment systems also benefits from this, as the model shifts from 
authentication of customers to mere authorization of payments. This approach rules out 


whole classes of attacks such as phishing [Gar+07| or credit card fraud [SDıol. 


3. GNU Taler must enable the state to tax income and crack down on illegal business 
activities. 


As a payment system must still be legal to operate and use, it must comply with these 
requirements. Furthermore, we consider levying of taxes as beneficial to society. 
4. GNU Taler must prevent payment fraud. 


This imposes requirements on the security of the system, as well as on the general design, 
as payment fraud can also happen through misleading user interface design or the lack of 
cryptographic evidence for certain processes. 
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5. GNU Taler must only disclose the minimal amount of information necessary. 


The reason behind this goal is similar to (2). The privacy of buyers is given priority, but 
other parties such as merchants still benefit from it, for example, by keeping details about 
the merchant’s financials hidden from competitors. 


6. GNU Taler must be usable. 


Specifically it must be usable for non-expert customers. Usability also applies to the inte- 
gration with merchants, and informs choices about the architecture, such as encapsulating 
procedures that require cryptographic operations into an isolated component with a simple 
API. 


7. GNU Taler must be efficient. 


Approaches such as proof-of-work are ruled out by this requirement. Efficiency is necessary 
for GNU Taler to be used for micropayments. 


8. GNU Taler must avoid single points of failure. 


While the design we present later is rather centralized, avoiding single points of failure is still 
a goal. This manifests in architectural choices such as the isolation of certain components, 
and auditing procedures. 


g. GNU Taler must foster competition. 


It must be relatively easy for competitors to join the systems. While the barriers for this 
in traditional financial systems are rather high, the technical burden for new competitors 
to join must be minimized. Another design choice that supports this is to split the whole 
system into smaller components that can be operated, developed and improved upon 
independently, instead of having one completely monolithic system. 


1.2 Features of Value-based Payment Systems 


There are many different possible features that have been proposed for value-based (sometimes 
called token-based) payment systems in the past. While we will discuss existing work on e-cash 
in more detail in Section [2.3.1] we will begin by a brief summary of the possible features that 
value-based payment systems could provide, and clarify which high-level features we chose to 
adopt for GNU Taler. 


12.1 Offline vs Online Payments 


Anonymous digital cash schemes since Chaum were frequently designed to allow the 
merchant to be offline during the transaction, by providing a means to deanonymize customers 
involved in double-spending, typically by encoding the customer's identity into their coins in a 
way that makes it only possible to decode the identity with two spending transcripts. 

This approach is problematic in practice, as customers that restore a wallet from backup might 
accidentally double-spend and would then face punishment for it. Enforcing punishment for 
double-spenders can be rather difficult as well, since the double-spender might have signed 
up with a false identity or might already have fled to another country, and a large number of 
merchants might already have been defrauded with the same coins. 

Should the issuer of e-cash be compromised, an attacker could issue coins that fail to identify 
a culprit or even blame somebody else when they are double-spent. In an offline e-cash system, 
the detection of such an event is greatly delayed compared to systems with online spending, 
which can immediately detect when more coins are spent than were issued. 

Thus, in GNU Taler, we decided that all coins must be immediately deposited online during 
a purchase. Only either a merchant or a customer needs to be online, since one of the two can 
forward messages to the payment service provider for the other. 
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12.2 Change and Divisibility 


Customers do not always have the right set of coins available to exactly cover the amount to be 
paid to a merchant. With physical cash, the store would give the customer change. For e-cash, 
the situation is more complex, as the customer would have to make sure that the change has not 
already been spent, does not violate their anonymity and the merchant does not have a digital 
“copy” of the change tokens that the merchant can spend before the customer. Note that it would 
be unwise to always withdraw the correct amount of e-cash directly before a purchase, as it 
creates a temporal correlation between the non-anonymous withdrawal event and the spending 
event. 

Most modern e-cash schemes instead deal with exact spending by providing divisibility of 
coins, where the customer can decide to only spend part of a coin. A significant chunk of the 
e-cash literature has been concerned with developing schemes that allow the individual, divided 
parts of a coin to be unlinkable (thus preserving anonymity) and to optimize the storage costs for 
wallets and the communication cost of withdrawals. 

The current state of the art for divisible e-cash achieves constant-time withdrawal and 
wallet storage cost for coins that can be split into an arbitrary but fixed (as a system parameter) 
number of pieces. A continuous "chunk" of the smallest pieces of a coin can be spent with 
constant-time communication complexity. 

While this sounds attractive in theory, these results are mostly of academic interest, as the 
storage and/or computational complexity for the party that is checking for double spending of 
coins remains enormous: each smallest piece of every coin needs to be recorded and checked 
individually. When paying $10.00 with a coin that supports division into cent pieces, 1000 
individual coin pieces must be checked for double spending and recorded, possibliy in compressed 
form to trade storage costs for more computation. 

For GNU Taler, we use a rather simple and practical approach, made possible by requiring 
participants to be online during spending: coins can be fractionally spent without having divisible, 
unlinkable parts. The remaining value on a coin that was spend (and thus revealed) can be used 
to withdraw fresh, unlinkable coins. The protocol to obtain change takes additional measures 
to ensure that it cannot be misused to facilitate untaxed transactions. Giving change for e- 
cash has been proposed before [TWo1], but to the best of our knowledge, the idea of 


income-transparent change is novel. 


12.3 Anonymity Control 


Some proposed e-cash protocols contain mechanisms to allow selective deanonymization of 
transactions for scenarios involving crime [SToo], specifically blackmailing and tax evasion. 

Unfortunately this does not really work as a countermeasure against blackmailing in practice. 
As noted in the paper that initially described such a mechanism for blind signatures [SPCos], a 
blackmailer could simply request to be paid directly with plain, blindly signed coins, and thereby 
completely circumvent the threat of revocable anonymity. 

GNU Taler provides income transparency as a measure against tax evasion. We furthermore 
describe a different approach in a blackmailing scenario in Section [2.2.5] which we believe is more 
practical in dissuading blackmailers in practice. 


1.2.4 User Suspension 


Anonymous user suspension has been proposed as another mechanism to punish 
users suspected in illicit activities by preventing then from making further transactions until the 
suspension is lifted. Anonymous suspension is based on transactions; the user involved in a 
particular transaction is suspended, but their identity is not revealed. 

While the approach is interesting, it is not practical, as it requires a single permanent key pair 
to be associated with each user. If a user claims they lost their private key and requests a new key 
pair, their suspension would be effectively lifted. Suspending users from a dominant payment 
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system is also socially problematic, as excluding them from most commercial activities would 
likely be a disproportionate and cruel punishment. 


1.2.5 Transferability 


Transferability is a feature of certain e-cash systems that allows transfer of e-cash between two 
parties without breaking anonymity properties ae Contemporary systems that offer this 
type of disintermediation attract criminal activity [Ric16| 

GNU Taler specifically provides roughly the opposite of this property, namely income trans- 
parency, to guarantee that e-cash is not easily abused for tax evasion. Mutually trusting users, 
however, can share ownership of a coin. 


1.2.6 Atomic Swaps 


Atomic swaps (often called “fair exchange” in the e-cash literature) are a feature of some e-cash 
systems that allows e-cash to be exchanged against some service or (digital) product, with a 
trusted third party ensuring that the payee receives the payment if and only if they correctly 
provided the merchandise. 


GNU Taler supports Camenisch-style atomic swaps [CLMo7], as explained in Section [3.7.2] 


12.7 Refunds 


GNU Taler allows merchants to provide refunds to customers during a limited time after the 
coins for the payment were deposited. The merchant signs a statement that effectively allows the 
customer to reclaim a previously spent coin. Customers can request anonymous change for the 
reclaimed amount. 

While this is a rather simple extension, we are not aware of any other e-cash system that 
supports refunds. 


1.3 User Experience and Performance 


For adoption of a payment system, the user experience is critical. Thus, before diving into how 
GNU Taler is implemented, we begin by showing how GNU Taler looks from the perspective of an 
end user in the context of web payments, in a desktop browser (Chromium). 

To use GNU Taler, the user must first install a browser extension (Figure [.1). Once installed, 
the user can open a pop-up window by clicking on the Taler logo, to see the initially empty wallet 
balance (Figure [1.2}. 

The customer logs into their online bank—a simple demo bank in our case-to withdraw digital 
cash from their bank account into their wallet (Figures[ı.3]and [14]. Our demo uses Kupos as 
an imaginary currency. Before the user is asked to confirm, they are given the option to view 
details about or change the default exchange provider, the GNU Taler payment service provider 
(Figure [1.5). 

With a real bank, a second factor (such as a mobile TAN) would now be requested from the 
user. Our demo instead asks the user to solve a simple CAPTCHA (Figure [1.6]. The amount 
withdrawn—minus withdrawal fees—is now available as e-cash in the wallet (Figure [1.7). 

The customer can now go to an online shop to spend their digital cash. We've implemented 
a shop that sells single chapters from Richard Stallman’s essay collection “Free Software, Free 
Society” (Figure [1.8). The user selects an essay, and is then immediately presented with a 
confirmation page rendered by the wallet (Figure [ı.o). After paying, the user can immediately 
read the article (Figure[r.10). 

Our benchmarks, discussed in Chapter [4|show that a single machine can support around 1000 
payments per second, and our implementation is easily amenable to further scaling. 
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** Taler Demo X Y æ GNU Taler Wallet- x \ `, dev 
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@ Add"GNU Taler Wallet"? 
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_@ > GNU Taler V 
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Figure 1.1: The user is prompted to install the wallet. 
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Figure ı.2: The wallet popup shows an empty balance. 


The extra computation required in the customer’s wallet is in the order of a few hundred 
milliseconds even on typical mobile or tablet devices, and thus barely noticeable. 
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GNU Taler is based on anonymous e-cash. Anonymous e-cash was invented by David Chaum 
in the 1980s [Cha83]. The idea behind Chaumian e-cash is both simple and ingenious, and can 
be best illustrated with the carbon paper] analogy: A long, random serial number is generated, 
for example, by throwing a die a few dozen times, and written on a piece of paper. A carbon 
paper is placed on top, with the pigmented side facing down, and both pieces of paper are put 
into an opaque envelope. The envelope is now sealed and brought to a bank. The bank draws a 
signature on the outside of the envelope, which presses through to the piece of paper with the 
serial number. In exchange for the signed envelope, the bank deducts a fixed amount (say five 
dollars) from the customer’s bank account. Under the (admittedly rather strong) assumption 
that the bank's signature cannot be forged, the signed piece of paper with the serial number is 
now an untraceable bank note worth five dollars, as the bank signed it without seeing the serial 
number inside the envelope! Since the signed paper can be easily copied, merchants that accept it 
as payment must check the bank’s signature, call the bank and transmit the serial number. The 


3Carbon paper is a paper coated with pigment (originally carbon) on one side. When put face-down between two 
sheets of normal paper, the pressure from writing with a pen or typewriter on the first layer causes pigment to be 
deposited on the paper beneath, allowing a copy to be made. 
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Taler Demo Welcome to the KUDOS Bank! 
Bank 


Please login! 


This part of the demo shows how Please login to see this page. 

a bank that supports Taler 

directly would work. In addition to (jsemame password 

using your own bank account, 

you can also see the transaction 

history of some Public Accounts. If you are a new customer, please register. Registration is fast and gratis, and it gives you a 
registration bonus of 100 KUDOS! 


Other parts of the demo: To view transactions of public accounts, please click here. 


Figure 1.3: The bank asks for login details. 


æ Chrome Web Store x Y KUDOS Bank - Tal x Wan dev 


€ C | Á Secure | https://bank.demo.taler.net/profile * GO 


Taler Demo Welcome Florian Dold! [Logout] 


Ban k Account: # 421 
Current balance: 100.00 KUDOS 


This part of the demo shows how 


a bank that supports Taler ; A : : 
directly would work. In addition to Withdraw digital coins using Taler 


using your own bank account, 


you can also see the transaction Amount to withdraw: 5.00 Y KUDOS Select exchange provider 
history of some Public Accounts. 


Figure 1.4: Account page of the demo bank. 


æ Chrome Web Store x) O Taler Wallet: Selec: x V — dav 
€ C | % GNU Taler Wallet | chrome-extension://millncjiddlpgdmkklmhfadpacifaonc/src/w Icon reate e IO) 
66 ———————— o 
GNU Taler Wallet 
You are about to withdraw 5 KUDOS from your bank account into your 
wallet. 


Using exchange provider https://exchange.demo.taler.net/. The 
exchange provider will charge 0.2 KUDOS in fees. 


The exchange is audited by a trusted auditor. 


Accept fees and withdraw Change Exchange Provider 


bFee and Spending Details 
p» Auditor Details 


Figure 1.5: Exchange selection dialog in the wallet. 
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æ Chrome Web Store x /*? KUDOSBank-Tal- x \\ ^ dev 


< C | & Secure | https://bank.demo.taler.net/pin/question?amount_currency=KUDOS&amount_fraction=O&amount_value=5&excha... y © 
Taler Demo PIN/TAN: Confirm transaction 


Ban k KUDOS Bank needs to verify that you intend to withdraw KUDOS:5.00 from 
https:/lexchange.demo.taler.net/. To prove that you are the account owner, please answer the 
following "security question" (*): 


This part of the demo shows how 


a bank that supports Taler What is 3 + 8? 
directly would work. In addition to 

using your own bank account, | Ok 
you can also see the transaction 

history of some Public Accounts. (*) A real bank should ask for a PIN/TAN instead of a simple calculation. For example by sending a one time password to the 
customer's mobile or providing her a random password generator. 


NOTE: the bank letely JavaScript 
Other parts of the demo: a 


Figure 1.6: PIN/TAN dialog of the demo bank. 


“e Chrome Web Store x Y © KUDOS Bank - Tale x V ^ dev 
€ C | @ Secure | https://bank.demo.taler.net/profile x0 


Balance History Debug 


Bank Account: # 421 4 e 8 KUDOS 


Current balance: 95.00 KUDOS Return Electronic Cash to Bank Account 

This part of the demo shows how Manage Trusted Auditors and Exchanges 

a bank that supports Taler “Withdrawal successful! | ) 
directly would work. In addition to 

using your own bank account, 


you can also see the transaction Withdraw digital coi 
history of some Public Accounts. 


Taler Demo Welcome Flori. 


Amount to withdraw: 5.00 
Other parts of the demo: 


+ Introduction 


Mlivra tenmntre 


Figure 1.7: After a successful withdrawal, the balance is shown in the wallet. 
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æ Chrome Web Store x 


€ C | â Secure 


Taler Demo 


Shop 


On this page you can buy 
articles using an imaginary 
currency (for now). The articles 
are chapters from Richard 
Stallman's book "Free Software, 
Free Society", which is also 
published by the FSF and 
available gratis at gnu.org. 


Introduction 
Bank 
Essay Shop 
Donations 


You can learn more about Taler 
on our main website. 


https://shop.demo.taler.net 


/ €? Taler Donation Der x 


Essay Shop: Free Software, Free Society 


This is the second edition of Free Software, Free Society: Selected Essays of Richard M. Stallman. 
Free Software Foundation 

51 Franklin Street, Fifth Floor 

Boston, MA 02110-1335 

Copyright € 2002, 2010 Free Software Foundation, Inc. 


Verbatim copying and distribution of this entire book are permitted worldwide, without royalty, in any medium, provided 
this notice is preserved. Permission is granted to copy and distribute translations of this book from the original English 
into another language provided the translation has been approved by the Free Software Foundation and the copyright 
notice and this permission notice are preserved on all copies. 


ISBN 978-0-9831592-0-9 


Chapters 


Click on an individual chapter to to purchase it. You can get free, virtual money to buy articles on 
this page at the bank. 


Foreword 


Every generation has its philosopher—a writer or an artist who captures the imagination of a 
time. Sometimes these philosophers are recognized as such; often it takes generations before 
the connection is made real. But recognized or not, a time gets marked by the people who speak 
its ideals, whether in the whisper of a poem, or the blast of a political movement. (Read more...) 


Preface to the Second Edition 


Figure 1.8: Landing page of a store that sells essays. 


2 Chrome Web Store x Y @ Taler Wallet: Confit x 


€ C | # GNU Taler Wallet | chrome-extension:// icjiddlpgdmkklmhfadpacifaonc/src/webex/pages/confirm-contract.htmlÜ?contract 
(C 


GNU Taler Wallet 

The merchant Free Software Foundation offers you to purchase: 
Essay: 4. The GNU Manifesto 

The total price is 0.5 KUDOS (plus 0.1 KUDOS fees). 


Confirm payment 


show more details 


Figure 1.9: Payment prompt for an essay. Rendered by the wallet. 


10 CHAPTER 1. INTRODUCTION 


& Chrome Web Store x Y © Taler Donation Der x \\_ dev 


< G | @ Secure | https shop.demo.taler.net ay/4._The_GNU_Manifesto * @ 


Taler Demo 4. The GNU Manifesto 


The GNU Manifesto was written by Richard Stallman at the beginning of the GNU 

Project, to ask for participation and support. For the first few years, it was updated in 

Sho p minor ways to account for developments, but now it seems best to leave it unchanged as 
most people have seen it. 


Since that time, we have learned about certain common misunderstandings that different 
On this page you can buy wording could help avoid. Footnotes added since 1993 help clarify these points. 


articles using an imaginary 

currency (for now). The articles For up-to-date information about the available GNU software, please see the information 
are chapters from Richard available on our web server, in particular our list of software. For how to contribute, see 
Stallman's book "Free Software, http://gnu.org/help . 

Free Society", which is also 


published by the FSF and What's GNU? Gnu's Not Unix! 
available gratis at gnu.org. 


GNU, which stands for Gnu's Not Unix, is the name for the complete Unix-compatible software 
system which | am writing so that | can give it away free to everyone who can use it. (12) Several 
* Introduction other volunteers are helping me. Contributions of time, money, programs and equipment are greatly 


nandad 


Figure 1.10: Essay successfully purchased by the user. 


bank keeps a register of all serial numbers that have been used as payment before. If the serial 
number is already in the bank’s register, the bank informs the merchant about the attempted 
double spending, and the merchant then rejects the payment. 

The digital analogue of this process is called a blind signature, where the signer knows that it 
gave a digital signature, but does not know the contents of the message that it signed. 

In this document, we use coin to refer to a token of value in an e-cash system. Note that the 
analogy of a coin does not always hold up, as certain types of operations possible in some e-cash 
schemes, such as partial spending, divisibility, etc., do not transfer to physical coins. 

We have the following security and correctness properties for GNU Taler (formally defined in 


Chapter (3): 


* Anonymity guarantees that transactions cannot be correlated with withdrawals or other 
transactions made by the same customer. 


e Unforgeability guarantees that users cannot spend more e-cash than they withdrew. 


* Conservation guarantees that customers do not lose money due to interrupted protocols or 
malicious merchants; they can always obtain anonymous change or a proof of successful 
spending. 


* Income transparency guarantees that mutually distrusting parties are unable to reliably 
transfer e-cash between them without the income of participants being visible to tax 
auditors. 


While anonymity and unforgeability are common properties of e-cash, we are not aware of 
any other treatments of income transparency and conservation. 


15 Roadmap 


Chapter [2] describes the high-level design of GNU Taler, and compares it to payment systems 
found in the academic literature and real-world usage. Chapter þ]first gives a gentle introduction 
to provable security (which can be skipped by readers with a background in cryptography), and 
then defines security properties for income-transparent, anonymous e-cash. The cryptographic 
protocols for GNU Taler are defined in detail, and proofs are given that our protocols satisfy the 
security properties defined earlier. In Chapter [4] the implementation of GNU Taler is described, 
and the performance and scalability is evaluated. Chapter [5] discusses future work and missing 
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pieces to deploy GNU Taler in production. Chapter [6]concludes with an outlook on the potential 
impact and practical relevance of this work. 
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CHAPTER 1. INTRODUCTION 


Chapter 2 


GNU Taler, an Income-Transparent 
Anonymous E-Cash System 


This chapter gives a high-level overview of the design of GNU Taler, based on the requirements 
discussed in Chapter |r| The cryptographic protocols and security properties are described and 
analyzed in detail in Chapter[3} A complete implementation with focus on of Web payments is 
discussed in Chapter l4] 


24 Design of GNU Taler 


GNU Taler is based on the idea of Chaumian e-cash [Cha83], with some differences and additions 
explained in the following sections. Other variants and extensions of anonymous e-cash and blind 
signatures are discussed in Section|2.3.1] 


2.1.1 Entities and Trust Model 


GNU Taler consists of the following entities (seel2.1): 


* The exchanges serve as payment service provider for a financial transaction between a 
customer and a merchant. They hold bank money in escrow in exchange for anonymous 
digital coins. 


The customers keep e-cash in their electronic wallets. 


The merchants accept digital coins in exchange for digital or physical goods and services. 
The digital coins can be deposited with the exchange, in exchange for bank money. 


The banks receive wire transfer instructions from customers and exchanges. A customer, 
merchant and exchange involved in one GNU Taler payment do not need to have accounts 
with the same bank, as long as wire transfers can be made between the respective banks. 


The auditors, typically run by trusted financial regulators, monitor the behavior of exchanges 
to assure customers and merchants that exchanges operate correctly. 


In GNU Taler, the exchanges can be separate entities from the banks. This fosters competition 
between exchanges, and allows Taler to be deployed in an environment with legacy banks that do 
not support Taler directly. 

If a customer wants to pay a merchant, the customer needs to hold coins at an exchange that 
the merchant trusts. To make the selection of trusted exchanges simpler, merchants and customers 
can choose to automatically trust all exchanges audited by a certain auditor. 
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verify 
Exchange || Auditor 


spend coins 
Customer |—————- | Merchant 


Figure 2.1: High-level overview of the different components of GNU Taler, banks are omitted. 


The exchange is trusted to hold funds of its customers in escrow and to make payments to 
merchants when digital coins are deposited. Customer and merchant can have assurances about 
the exchange’s liquidity and operation though the auditor, which would typically be run by 
financial regulators or other trusted third parties. 


2.1.2 System Assumptions 


We assume that an anonymous, bi-directional communication channe["] is used for all communi- 
cation between the customer and the merchant, as well as for obtaining unlinkable change for 
partially spent coins from the exchange and for retrieving the exchange’s public keys used in 
verifying and blindly signing coins. The withdrawal protocol, on the other hand, does not require 
an anonymous channel to preserve the anonymity of electronic coins. 


During withdrawal, the exchange knows the identity of the withdrawing customer, as there are 
laws, or bank policies, that limit the amount of cash that an individual customer can withdraw in 
a given time period [Bad15|[Reuz5]. GNU Taler is thus only anonymous with respect to payments. 
While the exchange does know their customer (KYC), it is unable to link the known identity of the 
customer that withdrew anonymous digital coins to the purchase performed later at the merchant. 


While customers can make untraceable digital cash payments, the exchange will always learn 
the merchants’ identity, which is necessary to credit their accounts. This information can also 
be used for taxation, and GNU Taler deliberately exposes these events as anchors for tax audits 
on merchants’ income. Note that while GNU Taler enables taxation, it does not implement any 
automatic taxation. 


GNU Taler assumes that each participant has full control over their system] We assume the 
contact information of the exchange is known to both customer and merchant from the start, and 
the customer can authenticate the merchant, for example, by using X.509 certificates [Yee13]. A 
GNU Taler merchant is expected to deliver the service or goods to the customer upon receiving 
payment. The customer can seek legal relief to achieve this, as the customer receives cryptographic 
evidence of the contract and the associated payment. 


but does not provide perfect anonymity f 

?Full control goes both ways: it gives the customer the freedom to run their own software, but also means that 
the behavior of fraudulent customers cannot be restricted by simpler technical means such as keeping balances on 
tamper-proof smart cards, and thus can lead to an overall more complex system. 


TAn anonymization layer like Tor |DMSo4] can provide a practical approximation of such a communication channel, 
y: yt 4 P P PP 
Joh+13 
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2.1.3 Reserves 


A reserve refers to a customer’s non-anonymous funds at an exchange, identified by a reserve 
public key. Suppose a customer wants to convert money into anonymized digital coins. To do 
that, the customer first creates a reserve private/public key pair, and then transfers money via 
their bank to the exchange. The wire transfer instruction to the bank must include the reserve 
public key. To withdraw coins from a reserve, the customer authenticates themselves using the 
corresponding reserve private key. 

Typically, each wire transfer is made with a fresh reserve public key and thus creates a new 
reserve, but making another wire transfer with the same reserve public key simply adds funds to 
the existing reserve. Even after all funds have been withdrawn from a reserve, customers should 
keep the reserve key pair until all coins from the corresponding reserve have been spent, as in the 
event of a denomination key revocation (see Section [2.2.1) the customer needs this key to recover 
coins of revoked denominations. 

The exchange automatically transfers back to the customer’s bank account any funds that 
have been left in a reserve for an extended amount of time, allowing customers that lost their 
reserve private key to eventually recover their funds. If a wire transfer to the exchange does not 
include a valid reserve public key, the exchange transfers the money back to the sender. 

Figure|2.2] illustrates the state machine for a reserve. Long-terms states are shown in boxes, 
while actions are in circles. The final state is in a double-circle. A reserve is first filled by a wire 
transfer. The amount in it is reduced by withdraw operations. If the balance reaches zero, the 
reserve is drained. If a reserve is not drained after a certain amount of time, it is automatically 
closed. A reserve can also be refilled via a recoup action (see Section in case that the 
denomination of an unspent coin that was withdrawn from the reserve is revoked. 

Instead of requiring the customer to manually generate reserve key pairs and copy them onto 
a wire transfer form, banks can offer tight integration with the GNU Taler wallet software. In 
this scenario, the bank’s website or banking app provides a “withdraw to GNU Taler wallet” 
action. After selecting this action, the user is asked to choose the amount to withdraw from their 
bank account into the wallet. The bank then instructs the GNU Taler wallet software to create 
record of the corresponding reserve; this request contains the anticipated amount, the reserve 
key pair and the URL of the exchange to be used. When invoked by the bank, the wallet asks the 
customer to select an exchange and to confirm the reserve creation. The exchange chosen by the 
customer must support the wire transfer method used by the bank, which will be automatically 
checked by the wallet. Typically, an exchange is already selected by default, as banks can suggest 
a default exchange provider to the wallet, and additionally wallets have a pre-defined list of 
trusted exchange providers. Subsequently, the wallet hands the reserve public key and the bank 
account information of the selected exchange back to the bank. The bank—typically after asking 
for a second authentication factor from the customer—will then trigger a wire transfer to the 
exchange with the information obtained from the wallet. 

When the customer’s bank does not offer tight integration with GNU Taler, the customer can 
still manually instruct their wallet to create a reserve. The public key must then be included in a 
bank transaction to the exchange. When the customer’s banking app supports pre-filling wire 
transfer details from a URL or a QR code, the wallet can generate such a URL or QR code that 
includes the pre-filled bank account details of the exchange as well as the reserve public key. The 
customer clicks on this link or scans the QR code to invoke their banking app with pre-filled 
transaction details. Since there currently is no standardized format for pre-filled wire transfer 
details, we are proposing the payto:// URI format explained in Section [4.2.1] currently under 
review for acceptance as an JETF Internet Standard. 


2.1.4 Coins and Denominations 


Unlike plain Chaumian e-cash, where a coin just contains a serial number, a coin in Taler is a 
public/private key pair where the private key is only known to the owner of the coin. 
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filled reserve 


2i 


drained reserve 


Figure 2.2: State machine of a reserve. 
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A coin derives its financial value from a blind signature on the coin’s public key. The exchange 
has multiple denomination key pairs available for blind-signing coins of different financial values. 
Other approaches for representing different denominations are discussed in Section 2.3.1] 

Denomination keys have an expiration date, before which any coins signed with it must be 
spent or exchanged into newer coins using the refresh protocol explained in Section|2.1.6] This 
allows the exchange to eventually discard records of old transactions, thus limiting the records 
that the exchange must retain and search to detect double-spending attempts. If a denomination’s 
private key were to be compromised, the exchange can detect this once more coins are redeemed 
than the total that was signed into existence using that denomination key. Should such an incident 
occur, the exchange can allow authentic customers to redeem their unspent coins that were signed 
with the compromised private key, while refusing further deposits involving coins signed by 
the compromised denomination key (see Section [2.2.1). As a result, the financial damage of 
losing a private signing key is limited to at most the amount originally signed with that key, and 
denomination key rotation can be used to bound that risk. 

To prevent the exchange from deanonymizing users by signing each coin with a fresh de- 
nomination key, exchanges publicly announce their denomination keys in advance with validity 
periods that imply sufficiently strong anonymity sets. These announcements are expected to 
be signed with an offline long-term private master signing key of the exchange and the auditor. 
Customers should obtain these announcements using an anonymous communication channel. 

After a coin is issued, the customer is the only entity that knows the private key of the coin, 
making them the owner of the coin. Due to the use of blind signatures, the exchange does not 
learn the public key during the withdrawal process. If the private key is shared with others, they 
become co-owners of the coin. Knowledge of the private key of the coin and the signature over 
the coin’s public key by an exchange’s denomination key enables spending the coin. 


2.1.5 Partial Spending and Unlinkable Change 


Customers are not required to have exact change ready when making a payment. In fact, it should 
be encouraged to withdraw a larger amount of e-cash beforehand, as this blurs the correlation 
between the non-anonymous withdrawal event and the anonymous spending event, increasing 
the anonymity set. 

A customer spends a coin at a merchant by cryptographically signing a deposit permission with 
the coin’s private key. A deposit permission contains the hash of the contract terms, i.e., the details 
of the purchase agreement between the customer and merchant. Coins can be partially spent, and 
a deposit permission specifies the fraction of the coin’s value to be paid to the merchant. As 
digital coins are trivial to copy, the merchant must immediately deposit them with the exchange, 
in order to get a deposit confirmation or an error that indicates double spending. 

When a coin is used in a completed or attempted /aborted payment, the coin’s public key is 
revealed to the merchant/exchange, and further payments with the remaining amount would be 
linkable to the first spending event. To obtain unlinkable change for a partially spent (or otherwise 
revealed coin), GNU Taler introduces the refresh protocol, which consists of three steps: melt, reveal 
and link. The refresh protocol allows the customer to obtain new coins for the remaining amount 
on a coin. The old coin is marked as spent after it has been melted, while the reveal step generates 
the fresh coins. Using blind signatures to withdraw the refreshed coins makes them unlinkable 
from the old coin. 


2.1.6 Refreshing and Taxability 


One goal of GNU Taler is to make merchants' income transparent to state auditors, so that income 
can be taxed appropriately. Naively implemented, however, a simple refresh protocol could be 
used to evade taxes: the payee of an untaxed transaction would generate the private keys for the 
coins that result from refreshing a (partially spent) old coin, and send the corresponding public 
keys to the payer. The payer would execute the refresh protocol, provide the payee's coin public 
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keys for blind signing, and provide the signatures to the payee, who would now have exclusive 
control over the coins. 

To remedy this, the refresh protocol introduces a link threat: coins are refreshed in such a way 
that the owner of the old coin can always obtain the private key and exchange’s signature on the 
new coins resulting from refreshes, using a separate linking protocol. This introduces a threat to 
merchants that try to obtain untaxed income. Until the coins are finally deposited at the exchange, 
the customer can always re-gain ownership of them and could deposit them before the merchant 
gets a chance to do so. This disincentivizes the circulation of unreported income among untrusted 
parties in the system. 

In our implementation of the refresh and linking protocols, there is a non-negligible success 
chance (1, depending on system parameter x, typically > 3) for attempts to cheat during the 
refresh protocol, resulting in refreshed coins that cannot be recovered from the old coin via 
the linking protocol. Cheating during refresh, however, is still not profitable, as an unsuccessful 
attempt results in completely losing the amount that was intended to be refreshed. 

For purposes of anti-money-laundering and taxation, a more detailed audit of the merchant's 
transactions can be desirable. A government tax authority can request the merchant to reveal the 
business agreement details that match the contract terms hash recorded with the exchange. If a 
merchant is not able to provide these values, they can be subjected to financial penalties by the 
state in relation to the amount transferred by the traditional currency transfer. 


2.1.7 Transactions vs. Sharing 


Sharing—in contrast to a transaction—happens when mutually trusted parties simultaneously 
have access to the private keys and signatures on coins. Sharing is not considered a transaction, 
as subsequently both parties have equal control over the funds. A useful application for sharing 
are peer-to-peer payments between mutually trusting parties, such as families and friends. 


2.1.8 Aggregation 


For each payment, the merchant can specify a deadline before which the exchange must issue 
a wire transfer to the merchant's bank account. Before this deadline occurs, multiple payments 
from deposited coins to the same merchant can be aggregated into one bigger payment. This 
reduces transaction costs from underlying banking systems, which often charge a fixed fee per 
transaction. To incentivize merchants to choose a longer wire transfer deadline, the exchange can 
charge the merchant a fee per aggregated wire transfer. 

Figure(2.3]illustrates the state machine for processing deposits. Long-terms states are shown 
in boxes, while actions are in circles. The final state is in a double-circle. Dashed arrows show 
transitions based on timing and not external actions. A deposit is first created when a wallet 
makes a payment. A deposit comes with a refund deadline, and the wire transfer must not happen 
before that deadline. Once the refund deadline has passed, the deposit becomes ready. Even if 
a deposit is ready, it is not automatically wired. In fact, deposits may still be refunded in this 
state. A refund may be full (resulting in the deposit being done) or partial, in which case the 
remaining value is left in the same deposit state. A deposit comes with a second deadline, the wire 
deadline. Once that deadline has passed, the deposit is due and must be aggregated. Aggregation 
combines all deposits that are due, tiny or ready into one wire transfer. However, the amount of 
even an aggregated deposit may be too small to be executed by the banking system. In this case, 
the deposit transitions into the special state tiny until the aggregated amount meets the amount 
threshold. Once aggregated, the deposits are done. A wire transfer is first prepared and then 
pending. The transfer is finished once the bank has confirmed the transfer. 


2.1.9 Refunds 


The aggregation period also opens the opportunity for cheap refunds. If a customer is not happy 
with their product, the merchant can instruct the exchange to give the customer a refund before 
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deposit created 
deposit ready 
deposit due 


deposit tiny 


deposit done 


pending transfer 


finished transfer 


Figure 2.3: State machine of a deposit. 
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the wire transfer deadline has occurred. This effectively “undoes” the deposit of the coin, and 
restores the available amount left on it. The refresh protocol is then used by the customer on the 
coins involved in a refund, so that payments remain unlinkable. 


2.1.10 Fees 


In order to subsidize the operation of the exchange and enable a sustainable business model, the 
exchange can charge fees for most operations. For withdrawal, refreshing, deposit and refunds, 
the fee is dependent on the denomination, as different denominations might have different key 
sizes, security and storage requirements. 

Most payment systems hide fees from the customer by putting them to the merchant. This is 
also possible with Taler. As different exchanges (and denominations) can charge different fees, 
the merchant can specify a maximum amount of fees it is willing to cover. Fees exceeding this 
amount must be explicitly paid by the customer. 

Another consideration for fees is the prevention of denial-of-service attacks. To make "useless" 
operations, such as repeated refreshing on coins (causing the exchange to use relatively expensive 
storage), unattractive to an adversary, these operations must charge a fee. Again, for every refresh 
following a payment, the merchant can cover the costs up to a limit set by the merchant, effectively 
hiding the fees from the customer. 

Yet another type of fee are the wire transfer fees, which are charged by the exchange for every 
wire transfer to a merchant in order to compensate for the cost of making a transaction in the 
underlying bank system. The wire transfer fees encourage merchants to choose longer aggregation 
periods, as the fee is charged per transaction and independent of the amount. 

Merchants can also specify the maximum wire fee they are willing to cover for customers, 
along with an amortization rate for the wire fees. In case the wire fees for a payment exceed 
the merchant's chosen maximum, the customer must additionally pay the excess fee divided 
by the amortization rate. The merchant should set amortization rate to the expected number of 
transactions per wire transfer aggregation window. This allows the merchant to adjust the total 
expected amount that it needs to pay for wire fees. 
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2.1.11 The Withdraw Loophole and Tipping 


The withdraw protocol can be (ab)used to illicitly transfer money, when the receiver generates the 
coin’s secret key, and gives the public key to the party executing the withdraw protocol. We call 
this the “withdraw loophole”. This is only possible for one “hop”, as money can still not circulate 
among mutually distrusted parties, due to the properties of the refresh protocol. 

A “benevolent” use of the withdraw loophole is tipping, where merchants give small rewards 
to customers (for example, for filling out a survey or installing an application), without any 
contractual obligations or digitally signed agreement. 


Fixing the Withdraw Loophole 


In order to discourage the usage of the withdraw loophole for untaxed payments, the following 
approach would be possible: Normal withdraw operations and unregistered reserves are disabled, 
except for special tip reserves that are registered by the merchant as part of a tipping campaign. 
Customers are required to pre-register at the exchange and obtain a special withdraw key pair 
against a small safety deposit. Customer obtain new coins via a refresh operation from the 
withdraw key to a new coin. If customers want to abuse Taler for untaxed payments, they either 
need to risk losing money by lying during the execution of the refresh protocol, or share their 
reserve private key with the payee. In order to discourage the latter, the exchanges gives the safety 
deposit to the first participant who reports the corresponding private key as being used in an 
illicit transaction, and requires a new safety deposit before the customer is allowed to withdraw 
again. 
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However since the withdraw loophole allows only one additional “payment” (without any 
cryptographic evidence that can be used in disputes) before the coin must be deposited, these 
additional mitigations might not even be justified considering their additional cost. 


2.2 Auditing 


The auditor is a component of GNU Taler which would typically be deployed by a financial 
regulator, fulfilling the following functionality: 


* It regularly examines the exchange’s database and bank transaction history to detect 
discrepancies. 


* It accepts samples of certain protocol responses that merchants received from an audited 
exchange, to verify that what the exchange signed corresponds to what it stored in its 
database. 


* It certifies exchanges that fulfill the operational and financial requirements demanded by 
regulators. 


* It regularly runs anonymous checks to ensure that the required protocol endpoints of the 
exchange are available. 


* In some deployment scenarios, merchants need to pre-register with exchanges to fulfill 
know-your-customer (KYC) requirements. The auditor provides a list of certified exchanges 
to merchants, to which the merchant then can automatically KYC-register. 


* It provides customers with an interface to submit cryptographic proof that an exchange 
misbehaved. If a customer claims that the exchange denies service, it can execute a request 
on behalf of the customer. 


2.2.1 Exchange Compromise Modes 


The exchange is an attractive target for hackers and insider threats. We now discuss different 
ways that the exchange can be compromised, how to reduce the likelihood of such a compromise, 
and how to detect and react to such an event if it happens. 


Compromise of Denomination Keys and Revocation 


When a denomination key pair is compromised, an attacker can “print money” by using it 
to sign coins of that denomination. An exchange (or its auditor) can detect this when the 
number of deposits for a certain denomination exceed the number of withdrawals for that same 
denomination. 

We allow the exchange to revoke denomination keys, and wallets periodically check for such 
revocations. We call a coin of a revoked denomination a revoked coin. If a denomination key 
has been revoked, the wallets use the recoup protocol to recover funds from coins of revoked 
denominations. Once a denomination is revoked, new coins of this denomination can’t be 
withdrawn or used as the target denomination for a refresh operation. A revoked coin cannot be 
spent, and can only be refreshed if its public key was recorded in the exchange’s database (as 
spending/refresh operations) before it was revoked. 

The following cases are possible for recoup: 


1. The revoked coin has never been seen by the exchange before, but the customer can prove via 
a withdraw protocol transcript and blinding factor that the coin resulted from a legitimate 
withdrawal from a reserve. In this case, the exchange credits the reserve that was used to 
withdraw the coin with the value of the revoked coin. 
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2. The coin has been partially spent. In this case, the exchange allows the remaining amount 
on the coin to be refreshed into fresh coins of non-revoked denominations. 


3. The revoked coin Cg has never been seen by the exchange before, was obtained via the 
refresh protocol, and the exchange has an existing record of either a deposit or refresh 
for the ancestor coin CA that was refreshed into the revoked coin Cr. If the customer can 
prove this by showing a corresponding refresh protocol transcript and blinding factors, the 
exchange credits the remaining value of Cr on Cy. It is explicitly permitted for CA to be 
revoked as well. The customer can then obtain back their funds by refreshing CA. 


These rules limit the maximum financial damage that the exchange can incur from a compro- 
mised denomination key D to 2nv, with n being the maximum number of D-coins simultaneously 
in circulation and v the financial value of a single D-coin. Say denomination D was withdrawn 
by legitimate users n times. As soon as the exchange sees more than n pairwise different D-coins, 
it must immediately revoke D. An attacker can thus at most gain nv by either refreshing into 
other non-revoked denominations or spending the forged D-coins. The legitimate users can then 
request a recoup for their coins, resulting in a total financial damage of at most 2nv. 

With one rare exception, the recoup protocol does not negatively impact the anonymity of 
customers. We show this by looking at the three different cases for recoup on a revoked coin. 
Specifically, in case (1), the coin obtained from the credited reserve is blindly signed, in case 
(2) the refresh protocol guarantees unlinkability of the non-revoked change, and in case (3) the 
revoked coin Cg is assumed to be fresh. If Cr from case (3) has been seen by a merchant before in 
an aborted /unfinished transaction, this transaction would be linkable to transactions on CA. Thus, 
anonymity is not preserved when an aborted transaction coincides with revoked denomination, 
which should be rare in practice. 

Unlike most other operations, the recoup protocol does not incur any transaction fees. The 
primary use of the protocol is to limit the financial loss in cases where an audit reveals that the 
exchange's private keys were compromised, and to automatically pay back balances held in a 
customers' wallet if an exchange ever goes out of business. 

To limit the damage of a compromise, the exchange can employ a hardware security module 
that contains the denomination secret keys, and is pre-programmed with a limit on the number 
of signatures it can produce. This might be mandated by certain auditors, who will also audit the 
operational security of an exchange as part of the certification process. 


Compromise of Signing Keys 


When a signing key is compromised, the attacker can pretend to be a merchant and forge deposit 
confirmations. To forge a deposit confirmation, the attacker also needs to get a customer to sign a 
contract from the adversary (which should include the adversary's banking details) with a valid 
coin. The attack here is that the customer is allowed to have spent the coin already. Thus, a 
deposit of the resulting deposit permission would result in a rejection from the exchange due to 
double spending. By forging the deposit confirmation using the compromised signing key, the 
attacker can thus claim in court that they properly deposited the coin first and demand payment 
from the exchange. 

We note that indeed an evil exchange could simply fail to record deposit permissions in its 
database and then fail to execute them. Thus, given a merchant presenting a deposit confirmation, 
we need a way to establish whether this is a case of an evil exchange that should be compelled to 
pay, or a case of a compromised signing key and where payouts (and thus financial damage to 
the exchange) can legitimately be limited. 

To limit the financial damage of a compromised signing key, merchants must be required to 
work with auditors to perform a probabilistic deposit auditing of the exchange. Here, the goal is 
to help detect the compromise of a signing key by making sure that the exchange does indeed 
properly record deposit confirmations. However, double-checking with the auditor if every deposit 
confirmation is recorded in the exchange's database would be too expensive and time-consuming. 
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Fortunately, a probabilistic method where merchants only send a small fraction of their deposit 
confirmations to the auditor suffices. Then, if the auditor sees a deposit confirmation that is not 
recorded in the exchange’s database (possibly after performing the next synchronization with the 
exchange’s database), it signals the exchange that the signing key has been compromised. 

At this point, the signing key must be revoked and the exchange will be required to investigate 
the security of its systems and address the issue before resuming normal operations. 

Still, at this point various actors (including the attacker) could still step forward with deposit 
confirmations signed by the revoked key and claim that the exchange owes them for their deposits. 
Simply revoking a signing key cannot lift the exchange’s payment obligations, and the attacker 
could have signed an unlimited number of such deposit confirmations with the compromised key. 
However, in contrast to honest merchants, the attacker will not have participated proportionally in 
the auditor’s probabilistic deposit auditing scheme for those deposit confirmations: in that case, 
the key compromise would have been detected and the key revoked. 

The exchange must still pay all deposit permissions it signed for coins that were not double- 
spent. However, for all coins where multiple merchants claim that they have a deposit confir- 
mation, the exchange will pay the merchants proportionate to the fraction of the coins that they 
reported to the auditor as part of probabilistic deposit auditing. For example, if 1% of deposits 
must be reported to the auditor according to the protocol, a merchant might be paid at most 
say 100+X times the number of reported deposits where X > 0 serves to ensure proper payout 
despite the probabilistic nature of the reporting. As a result, honest merchants have an incentive 
to correctly report the deposit confirmations to the auditor. 

Given this scheme, the attacker can only report a small number of deposit confirmations to 
the auditor before triggering the signing key compromise detection. Suppose again that 1% of 
deposit confirmations are reported by honest merchants, then the attacker can only expect to 
submit 100 deposit permissions created by the compromised signing key before being detected. 
The attacker’s expected financial benefit from the key compromise would then be the value of 
(100 + X) - 100 deposit permissions. 

Thus, the financial benefit to the attacker can be limited by probabilistic deposit auditing, and 
honest merchants have proper incentives to participate in the process. 


Compromise of the Database 


If an adversary would be able to modify the exchange, this would be detected rather quickly by 
the auditor, provided that the database has appropriate integrity mechanisms. An attacker could 
also prevent database updates to block the recording of spend operations, and then double spend. 
This is effectively equivalent to the compromise of signing keys, and can be detected with the 
same strategies. 


Compromise of the Master Key 


If the master key was compromised, an attacker could de-anonymize customers by announcing 
different sets of denomination keys to each of them. If the exchange was audited, this would be 
detected quickly, as these denominations will not be signed by auditors. 


2.2.2 Cryptographic Proof 


We use the term “proof” in many places as the protocol provides cryptographic proofs of which 
parties behave correctly or incorrectly. However, as point out, in practice financial systems 
need to provide evidence that holds up in courts. Taler’s implementation is designed to export 
evidence and upholds the core principles described in [MA14]. In particular, in providing the 
cryptographic proofs as evidence none of the participants have to disclose their core secrets. 
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2.2.3 Perfect Crime Scenarios 


GNU Taler can be slightly modified to thwart blackmailing or kidnapping attempts by criminals 
who intend to use the anonymity properties of the system and demand to be paid ransom in 
anonymous e-cash. 

Our modification incurs a slight penalty on the latency for customers during normal use and 
requires slightly more data to be stored in the exchange’s database, and thus should only be used 
in deployments where resistance against perfect crime scenarios is necessary. A payment system 
for a school cafeteria likely does not need these extra measures. 

The following modifications are made: 


1. Coins can now only be used in either a transaction or in a refresh operations, not a mix of 
both. Effectively, the customer’s wallet then needs to use the refresh protocol to prepare 
exact change before a transaction is made, and that transaction is made with exact change. 


This change is necessary to preserve anonymity in face of the second modification, but 
increases storage requirements and latency. 


2. The recoup protocol is changed so that a coin obtained via refreshing must be recovered 
differently when revoked: to recover a revoked coin obtained via refreshing, the customer 
needs to show the transcripts for the chain of all refresh operations and the initial withdrawal 
operation (including the blinding factor). Refreshes on revoked coins are not allowed 
anymore. 


After an attacker has been paid ransom, the exchange simply revokes all currently offered 
denominations and registers a new set of denomination with the auditor. Reserves used to pay 
the attacker are marked as blocked in the exchange’s database. Normal users can use the recoup 
protocol to obtain back the money they’ve previously had in revoked denominations. The attacker 
can try to recover funds via the (now modified) recoup protocol, but this attempt will not be 
successful, as the initial reserve is blocked. The criminal could also try to spend the e-cash 
anonymously before it is revoked, but this is likely difficult for large amounts, and furthermore 
due to income transparency all transactions made between the payment of the ransom and the 
revocation can be traced back to merchants that might be complicit in laundering the ransom 
payment. 

Honest customers can always use the recoup protocol to transfer the funds to the initial reserve. 
Due to modification (1), unlinkability of transactions is not affected, as only coins that were purely 
used for refreshing can now be correlated. 

We believe that our approach is more practical than the approaches based on tracing, since 
in a scheme with tracing, the attacker can always ask for a plain blind signature. With our 
approach, the attacker will always lose funds that they cannot immediately spend. Unfortunately 
our approach is limited to a kidnapping scenario, and not applicable in those blackmail scenarios 
where the attacker can do damage after they find out that their funds have been erased. 


2.2.4 Summary 


Figure [2.4]illustrates the overall state machine for processing coins. Long-terms states are shown 
in boxes, while actions are in circles. The final state is in a double-circle. Dashed arrows show 
transitions based on timing and not external actions. The red arrow shows an action that is 
allowed by the exchange but should never be done by wallets as it would break unlinkability. 

A coin begins as an unsigned planchet, which is either signed as part of the withdraw protocol 
or the refresh protocol. The most common scenario is that the fresh coin is deposited. This payment 
creates a deposit (see Figure [2.3) and either a dirty coin (if the payment was for a fraction of the 
coin’s value) or a spent coin. A spent coin can be refunded by the merchant, creating a dirty coin. 
Once the exchange has aggregated a coin and wired the amount to the merchant, a coin can no 
longer be refunded. 
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A fresh coin may also be subject to key revocation, at which point the wallet ends up with a 
revoked coin. At this point, the wallet can use the recoup protocol to recover the value of the coin. 
If the coin originated from a withdraw operation, the value is added back into the reserve, which 
is filled in the process (see Figure|2.2). If the coin originated from the refresh operation, this results 
in the old coin turning into a zombie coin, which can be refreshed again. 

Dirty coins and fresh coins can be melted. Dirty coins should always be melted automatically 
by the wallet as soon as possible as this is the only good way to use them while preserving 
unlinkability. A wallet should also automatically melt any fresh coins that are in danger of their 
denomination key nearing its (deposit) expiration time. If a wallet fails to do so, coins may expire, 
resulting in a loss for the coin’s owner. Dirty coins can also expire. In practice, this happens if the 
melt fee exceeds the residual value of the dirty coin. To melt a coin, the wallet must commit to 
one or more planchets and then demonstrate honesty when the commitment made for the refresh 
session is checked during the reveal step. If the wallet was honest, reveal yields fresh coins. 


2.3 Related Work 


2.3.1 Anonymous E-Cash 


Chaum's seminal paper [Cha85] introduced blind signatures and demonstrated how to use them 
for online e-cash. Later work [Cha+89 introduced offline spending, where additional 
information is encoded into coins in such a way that double spending reveals the culprit’s identity. 

Okamoto introduced the first efficient offline e-cash scheme with divisibility, a feature 
that allows a single coin to be spent in parts. With Okamoto’s protocol, different spending 
operations that used parts of the same coin were linkable. An unlinkable version of divisible 


e-cash was first presented by Canard [CGo7]. 
Camenisch's compact e-cash [CHLos]| allows wallets with 2” coins to be stored and withdrawn 


with storage, computation and computational costs in O(£). Each coin in the wallet, however, still 
needs to be spent separately. 

The protocol that can currently be considered the state-of-the-art for efficient offline e-cash was 
introduced by Pointcheval et al. [PST17]. It allows constant-time withdrawal of a divisible coin, 
and constant-time spending of a continuous “chunk” of a coin. While the pre-determined number 
of divisions of a coin is independent from the storage, bandwidth and computational complexity 
of the wallet, the exchange needs to check for double-spending at the finest granularity. Thus, 
highly divisible coins incur large storage and computational costs for the exchange. 

An e-cash system with multiple denominations with different financial values was proposed 
by Canard and Gouget |CGHo6] in the context of a divisible coupon system. 

One of the earliest mentions of an explicit change protocol can be found in [BGKg5]. Ian 
Goldberg’s HINDE system is another design that allows the merchant to provide change, but 
the mechanism could be abused to hide income from taxation] Another online e-cash protocol 
with change was proposed by Tracz [TWo1]. The use of an anonymous change protocol (called a 
“refund” in their context) for fractional payments has also been suggested for a public transit fees 
payment system [Rup-15]. Change protocols for offline e-cash were recently proposed [BY 18}. 
To the best of our knowledge, no change protocol with protections against tax evasion has been 
proposed so far, and all change protocols suggested so far can be (ab)used to make a payment 
into another wallet. 

Transferable e-cash allows the transfer of funds between customers without using the exchange 
as in intermediary [FPVoo]. 

Chaum also proposed wallets with observers as a mechanism against double spending. 
The observer is a tamper-proof hardware security module that prevents double-spending, while 
at the same time being unable to de-anonymize the user. 


3Description based on personal communication. HINDE was never published, but supposedly publicly discussed at 
Financial Crypto '98. 
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fresh coin 


dirty coin 


spent coin expired coin 


Figure 2.4: State machine of a coin. 
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Various works propose mechanisms to selectively de-anonymize customers or transactions 


that are suspected of criminal activities |SPC95 . Another approach suspends customers 
that were involved in a particular transaction, while keeping the customer anonymous [ASM11]. 


One of the first formal treatments of the provable security of e-cash was given dud 
The first complete security definition for blind signatures was given by Pointcheval [P596] and 
applied to RSA signatures later [PSoo]. While the security proof of RSA signatures requires the 
random oracle model, many blind signature schemes are provably secure in the standard model 
[PST17]. While most literature provides only “human-verified” security arguments, the 
security of a simple e-cash scheme has been successfully modeled in ProVerif [DKL:5], albeit only 
in the symbolic model. 


Implementations 


DigiCash was the first commercial implementation of Chaum's e-cash. It ultimately failed 
to be widely adopted, and the company filed for bankruptcy in 1998. Some details of the 
implementation are available [Sch98]. In addition to Chaum’s infamously paranoid management 
style [Anoog], reasons for DigiCash's failure could have been the following: 


DigiCash did not allow account-less operations. To use DigiCash, customers had to sign up 
with a bank that natively supports DigiCash. 


DigiCash did not support change or partial spending, negating a lot of the convenience and 
security of e-cash by requiring frequent withdrawals from the customer's bank account. 


The technology used by DigiCash was protected by patents, which stifled innovation from 
competitors. 


Chaum's published design does not clearly limit the financial damage an exchange might 
suffer from the disclosure of its private online signing key. 


To our knowledge, the only publicly available effort to implement anonymous e-cash is 
Opencoin [DPWo8]. However, Opencoin is neither actively developed nor used, and it is not clear 
to what degree the implementation is even complete. Only a partial description of the Opencoin 
protocol is available to date. 


Representing Denominations 


For GNU Taler, we chose to represent denominations of different values by a different public key 
for every denomination, together with a mapping from public key to financial value and auxiliary 
information about fees and expiration dates. This approach has the advantage that coins of higher 
denominations can be signed by denominations with a larger key size. 

Schoenmakers proposes an optimized implementation of multiple denomination that 
specifically works with RSA keys, which encodes the denomination in the public exponent e of 
the RSA public key, while the modulus N stays the same for all denominations. An advantage of 
this scheme is the reduced size of the public keys for a set of denominations. As this encoding 
is specific to RSA, it would be difficult for future versions of this protocol to switch to different 
blind signature primitives. More importantly, factoring N would lead to a compromise of all 
denominations instead of just one. 

Partially blind signatures can be used to represent multiple denominations by blindly signing 
the coin's serial number and including the financial value of the coin in the common information 
seen by both the signer and signee [AOoo]. 

The compact e-cash scheme of Martens allows constant-time withdrawal of wallets 
with an arbitrary number of coins, as long as the number of coins is smaller than some system 
parameter. This approach effectively dispenses with the need to have different denominations. 
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* Implementation. Is there an implementation? Is it proprietary (P), experimental (E), or free 
software (FS). 


* Offline Spending Can spending happen offline with delayed detection of double spenders, 
or is double spending detected immediately during spending? 


* Safe abort/backup. Is anonymity preserved in the presence of interrupted operations or 
restoration from backups? Inherently conflicts with offline double spending detection in 
all approaches that we are aware of. We specify “Y” also for schemes that do not explicitly 
treat aborts/backup, but would allow a safe implementation when aborts /backups happen. 


* Key expiration. We specify "?" for schemes that do not explicitly discuss key expiration, 
but do not fundamentally conflict with the concept. 


* Income transparency. We specify “Y” if income transparency is supported, "X" if some 
feature of the scheme conflicts with income transparency and "?" if it might be possible to 
add income transparency. 


* No trusted setup. In a trusted setup, some parameters and cryptographic keys are generated 
by a trusted third party. A compromise of the trusted setup phase can mean loss of 
anonymity. 


* Storage for wallet/exchange. The expected storage for coins adding up to arbitrary value n 
is specified, with some reasonable upper bound for n. 


* Change/Divisibility. Can customers pay without possessing exact change? If so, is it 
handled by giving change online (Onl.) or by divisible coins that support offline operation 
(Off.)? 


* Receipts & Refunds. The customer either can prove that they paid for a contract, or they 
can get their (unlinkable) money back. Also merchants can issue refunds for completed 
transactions. These operations must not introduce linkability or otherwise compromise the 
customer's anonymity. 


2.3.2. Blockchains 


The term “blockchain” refers to a wide variety of protocols and systems concerned with main- 
taining a ledger—typically involving financial transactions—in a distributed and decentralized 
manner[!l 

The first and most prominent system that would be categorized as a "blockchain" today] is 
Bitcoin [Nako8], published by an individual or group under the alias “Satoshi Nakamoto”. The 


^Even though there is a centralization tendency from various sources in practice ! 
5The paper that introduces Bitcoin does not mention the term “blockchain” 
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document timestamping service described in could be seen as an even earlier blockchain 
that predates Bitcoin by about 13 years and is still in use today. 

As the name implies, blockchains are made up of a chain of blocks, each block containing 
updates to the ledger and the hash code of its predecessor block. The chain terminates in a 
“genesis block” that determines the initial state of the ledger. 

Some of the most important decisions for the design of blockchains are the following: 


* The consensus mechanism, which determines how the participants agree on the current state 
of the ledger. 


In the simplest possible blockchain, a trusted authority would validate transactions and 
publish new blocks as the head of the chain. In order to increase fault tolerance, multiple 
trusted authorities can use Byzantine consensus to agree on transactions. With classical 
Byzantine consensus protocols, this makes the system robust with a malicious minority of 
up to 1/3 of nodes. While fast and appropriate for some applications, classical Byzantine 
consensus only works with a known set of participants and does not scale well to many 
nodes. 


Bitcoin instead uses Proof-of-Work (PoW) consensus, where the head of the chain that 
determines the current ledger state is chosen as the block that provably took the most “work” 
to construct, including the accumulated work of ancestor blocks. The work consists of 
finding a hash preimage n||c, where c are the contents of the block and n is a nonce, such 
that the hash H(n||c) ends with a certain number of zeroes (as determined by the difficulty 
derived from previous blocks). Under the random oracle, the only way to find such a nonce 
is by trial-and-error. This nonce proves to a verifier that the creator of the block spent 
computational resources to construct it, and the correctness is easily verified by computing 
H(n||c). The creator of a block is rewarded with a mining reward and transaction fees for 
transactions within the block. 


PoW consensus is not final: an adversary with enough computational power can create 
an alternate chain branching off an earlier block. Once this alternative, longer chain is 
published, the state represented by the earlier branch is discarded. This creates a potential 
for financial fraud, where an earlier transaction is reversed by publishing an alternate history 
that does not contain it. While it was originally believed that PoW consensus process is 
resistant against attackers that have less than a 51% majority of computational power, closer 
analysis has shown that a 21% majority sufficies [ES18]. 


A major advantage of PoW consensus is that the participants need not be known beforehand, 
and that Sybil attacks are impossible since consensus decisions are only dependent on the 
available computational power, and not on the number of participants. 


In practice, PoW consensus is rather slow: Bitcoin can currently support 3-7 transactions 
per second on a global scale. Some efforts have been made to improve Bitcoin's efficiency 
[Eya+16}|Vuk15], but overall PoW consensus needs to balance speed against security. 


Proof-of-Stake (PoS) is a different type of consensus protocol for blockchains, which intends 
to securely reach consensus without depleting scarce resources such as energy for computa- 
tion [BGM16;|Kwo14]. Blocks are created by randomly selected validators, which obtain a 
reward for serving as a validator. To avoid Sybil attacks and create economic incentives for 
good behavior, the probability to get selected as a validator is proportional to one’s wealth 
on the respective blockchain. Realizing PoS has some practical challenges with respect to 
economic incentives: As blocks do not take work to create, validators can potentially benefit 
from creating forks, instead of validating on just one chain. 


Algorand avoids some of the problems with PoW consensus by combining some of 
the ideas of PoW with classical Byzantine consensus protocols. Their proposed system does 
not have any incentives for validators. 
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Avalanche [Tea18] has been proposed as a scalable Byzantine Consensus algorithm for 
use with blockchains. It is based on a gossip protocol and is only shown to work in the 
synchronous model. 


* Membership and visibility. Blockchains such as Bitcoin or Ethereum with public membership 
and public visibility are called permissionless blockchains. Opposed to that, permissioned 
blockchains have been proposed for usage in banking, health and asset tracking applications 


[And+18}. 


* Monetary policy and wealth accumulation. Blockchains that are used as cryptocurrencies 
come with their own monetary policy. In the case of Bitcoin, the currency supply is limited, 
and due to difficulty increase in mining the currency is deflationary. Other cryptocurrencies 
such as duniteif] have been proposed with built-in rules for inflation, and a basic income 
mechanism for participants. 


* Expressivity of transactions. Transactions in Bitcoin are small programs in a stack-based 
programming language that are guaranteed to terminate. Ethereum |Woo14] takes this idea 
further and allows smart contracts with Turing-complete computation and access to external 
oracles. 


e Governance. Blockchain governance [ROH16 is a topic that received relatively 


little attention so far. As blockchains interact with existing legal and social systems across 
national borders, different sources of "truth" must be reconciled. 


Furthermore, consensus is not just internal to the operation of blockchains, but also external 
in the development of the technology. Currently small groups of developers create the rules 
for the operation of blockchains, and likewise have the power to change them. There is 
currently very little research on social and technological processes to find a "meta-consensus" 
on the rules that govern such systems, and how these rules can be adapted and changed in 
a consensus process. 


* Anonymity and Zero-Knowledge Proofs. Bitcoin transactions are only pseudoymous, the 
full transaction history is publicly available and leads to reduced anonymity in practice 


[RH13]. Tumblers [Bon+14| are an approach to increase the anonymity in Bitcoin- 


style cryptocurrencies by creating additional transactions to cover up the real owner and 
sources of funds. While newer tumblers such as TumbleBit [Hei+17] provide rather strong 
security guarantees, mixing incurs transaction costs. 


Some cryptocurrencies have direct support for anonymous transactions [Sun«17]. ZeroCash 
[Ben+14| uses zero-knowledge proofs to hide the sender, receiver and amount of a transac- 
tion. While ZeroCash currently relies on a trusted setup for unforgeability of its currency, 
more recent proposals dispense with that requirement [Ben+18}|Wah+18]. As the anonymity 
provided by ZeroCash facilitates tax evasion and use in other crimes, an additional, optional 
layer for privacy-preserving policy for taxation, spending limits and identity escrow has 


been proposed |GGM 16]. 


Practical guidance on what kind of blockchain is appropriate for an application, and if a 
blockchain is required in the first place, can be found in [WG17]. 


2.3.3 Approaches to Micropayments 


Micropayments refer to payments of very small value. Microtransactions would not be feasible in 
traditional payment systems due to high transaction costs, which might even exceed that value 
that is to be transferred. 


6Seelhttps://duniter.org/ 


2.3. RELATED WORK 31 


Peppercoin 


Peppercoin is a microdonation protocol. The main idea of the protocol is to reduce trans- 
action costs by minimizing the number of transactions that are processed directly by the exchange. 
Instead of always paying, the customer “gambles” with the merchant for each microdonation. 
Only if the merchant wins, the microdonation is upgraded to a macropayment to be deposited 
at the exchange. Peppercoin does not provide customer-anonymity. The proposed statistical 
method by which exchanges detect fraudulent cooperation between customers and merchants at 
the expense of the exchange not only creates legal risks for the exchange, but would also require 
that the exchange learns about microdonations where the merchant did not get upgraded to a 
macropayment. It is therefore unclear how Peppercoin would actually reduce the computational 
burden on the exchange. 


Tick Payments 


Tick payments were proposed by Pedersen as a general technique to amortize the cost 
for small, recurring payments to the same payee. The payer first makes an up-front deposit as 
one larger payment that involves the payment processor. To make a micropayment, the payer 
sends a message to the payee that authorizes the payee to claim a fraction of this deposit. Each 
further micropayment simply increases the fraction of the deposit that can be claimed, and only 
requires communication between payer and payee. The payee only needs to show the last message 
received from the payer to the payment processor in order to receive the accumulated amounts 
received through tick payments. 


Payment Channels and Lightning Network 


The Lightning Network is a proposed payment system that is meant to run on top of 
Bitcoin and enable faster, cheaper (micro-)transactions. It is based on establishing payment channels 
between Bitcoin nodes. A payment channel is essentially a tick payment where the deposit and 
settlement happens on a blockchain. The goal of the Lightning network is to route a payment 
between two arbitrary nodes by finding a path that connects the two routes through payment 
channels. The protocol is designed in such a way that a node on the path between the initial 
sender and final receiver can only receive a payment on a payment channel if it correctly forwards 
it to the next node. 

Experimental deployments of the Lightning network recently suffered heavily from denial-of- 
service attacks. 

BOLT is an anonymous payment channel for ZeroCash, and is intended to be used as 
a building block for a second-layer payment protocol like the Lightning Network. 


Side-chains 


Side-chains are an alternative approach to improve the scalability of blockchains, intended to 
be useful in conjunction with arbitrary smart contracts. The approach currently developed by 
the Ethereum project is described in the Plasma white paper [PB17]. Side-chains are separate 
blockchains, possibly with different rules and even consensus protocols than the main chain. 
Side-chains operate in parallel to the main Ethereum chain, and regularly publish “pointers” to 
the current head of the sidechain on the main chain. Funds can be moved from the main chain to 
the side-chain, and subsequently be moved off the side-chain by performing an "exit", during 
which the main chain verifies claims to funds on the side-chain according to the side-chain's rules. 

At the time of writing, Plasma is not yet implemented. Potential problems with Plasma include 
the high costs of exits, lack of access to data needed to verify exit claims, and associated potential 
for denial-of-service attacks. 
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2.3.4 Walled Garden Payment Systems 


Walled garden payment systems offer ease of use by processing payments using a trusted payment 
service provider. Here, the customer authenticates to the trusted service, and instructs the payment 
provider to execute a transaction on their behalf. In these payment systems, the provider basically 
acts like a bank with accounts carrying balances for the various users. In contrast to traditional 
banking systems, both customers and merchants are forced to have an account with the same 
provider. Each user must take the effort to establish his identity with a service provider to create 
an account. Merchants and customers obtain the best interoperability in return for their account 
creation efforts if they start with the biggest providers. As a result, there are a few dominating 
walled garden providers, with AliPay, ApplePay, GooglePay, SamsungPay and PayPal being the 
current oligopoly. 

As with card payment systems, these oligopolies are politically dangerous [Run11], and the 
lack of competition can result in excessive profit taking that may require political solutions 
to the resulting market failure. The use of non-standard proprietary interfaces to the payment 
processing service of these providers serves to reinforce the customer lock-in. 


2.3.5 Web Integration 


Finally, we will discuss software solutions to web payments. We consider other types of payments, 
including general payments and in particular hardware solutions as out of scope for this thesis. 


Web Payments API 


The Web Payments APT] is a JavaScript API offered by browsers, and currently still under 
development. It allows merchant to offer a uniform checkout experience across different payment 
systems. Unlike GNU Taler, the Web Payments API is only concerned with aspects of the checkout 
process, such as display of a payment request, selection of a shipping address and selection of a 
payment method. 

Currently only basic-card is supported across popular browsers. 

The Payment Handler API ]supports the registration of user-defined payment method handlers. 
Unfortunately the only way to add payment method handlers is via an HTTPS URL. This leaks 
all information to the payment service provider and precludes the implementation of privacy- 
preserving payment system handlers. 

In order to integrate Taler as a payment method, browsers would need to either offer Taler as 
a native, built-in payment method or allow an extension to register web payment handlers. 

The Web Payments Working Group discontinued work on a HTTP-based API for machine-to- 
machine payments) 


Payment Pointers 


Payment pointers are a proposed standard syntax for accounts that are able to receive payments. 
Unlike payto: / / URIs ( discussed in Section[4.2.1), payment pointers do not follow the generic 
URI syntax and only specify a pointer to the receiver's bank account in form of a HTTPS URI. 
Payment pointers do not specify any mechanism for the payment, but instead direct the user's 
browser to a website to carry out the payment. 


3-D Secure 


3-D Secure is a complex and widely deployed protocol that is intended to add an additional 
security layer on top of credit and debit card transactions. 


https://www.w3.org/TR/payment-request/ 
https://www.w3.org/TR/payment-handler/ 


https: //www.w3.org/TR/webpayments-http-api/ 


7See 
3See 
9See 
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The 3-D Secure protocol requires the use of inline frames on the HTML page of the merchant 
for extended verification/authentication of the user. This makes it hard or sometimes — such as 
when using a mobile browser — even impossible to tell whether the inline frame is legitimate or 
an attempt to steal information from the user. 

Traditionally, merchants bear most of the financial risk, and a key “feature” of the 3DS process 
compared to traditional card payments is to shift dispute liability to the issuer of the card—who 
may then try to shift it to the customer §2.4]. Even in cases where the issuer or the 
merchant remain legally first in line for liabilities, there are still risks customers incur from the 
card dispute procedures, such as neither them nor the payment processor noticing fraudulent 
transactions, or them noticing fraudulent transactions past the deadline until which their bank 
would reimburse them. The customer also typically only has a merchant-generated comment 
and the amount paid in their credit card statement as a proof for the transaction. Thus, the use 
of credit cards online does not generate any cryptographically verifiable electronic receipts for 
the customer, which theoretically enables malicious merchants to later change the terms of the 
contract. 

Beyond these primary issues, customers face secondary risks of identity theft from the personal 
details exposed by the authentication procedures. In this case, even if the financial damages are 
ultimately covered by the bank, the customer always has to deal with the procedure of notifying 
the bank in the first place. As a result, customers must remain wary about using their cards, 


which limits their online shopping [ibi14 p. 50]. 


Other Proprietary Payment APIs 


The Electronic Payment Standard URI scheme epspayment : is a proprietary/unregistered URI 
scheme used by predominantly Austrian banks and merchants to trigger payments from within 
websites on mobile devices. Merchants can register an invoice with a central server. The user's 
banking app is associated with the epspayment URI scheme and will open to settle the invoice. 
It lies conceptually between payto: // and taler:pay (see Section [4.1.5). A technical problem 
of epspayment is that when a user has multiple bank accounts at different banks that support 
epspayment, some platforms decide non-deterministically and without asking the user which 
application to launch. Thus, a user with two banking applications on their phone can often not 
chose which bank account is used for the payment. If payto were widely supported, the problem 
of registering / choosing bank accounts for payment methods could be centrally addressed by the 
browser / operating system. 

PayPal is a very popular, completely proprietary payment system provider. Its offer-based 
API is similar in the level of abstraction to Taler's reference merchant backend API. 

LaterPay is a proprietary payment system for online content as well as donations. It of- 
fers similar functionality to session-bound payments in Taler. LaterPay does not provide any 
anonymity. 
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Chapter 3 


Security of Income-Transparent 
Anonymous E-Cash 


We so far discussed Taler’s protocols and security properties only informally. In this chapter, we 
model a slightly simplified version of the system that we have implemented (see Chapter la), make 
our desired security properties more precise, and prove that our protocol instantiation satisfies 
those properties. 


3.1 Introduction to Provable Security 


Provable security [GM82 is a common approach for constructing formal 


arguments that support the security of a cryptographic protocol with respect to specific security 
properties and underlying assumptions on cryptographic primitives. 

The adversary we consider is computationally bounded, i.e., the run time is typically restricted 
to be polynomial in the security parameters (such as key length) of the protocol. 

Contrary to what the name might suggest, a protocol that is “provably secure" is not necessarily 
secure in practice [Damo7]. Instead, provable security results are typically based on 
reductions of the form “if there is an effective adversary A against my protocol P, then I can use A to 
construct an effective adversary A! against Q” where Q is a protocol or primitive that is assumed 
to be secure or a computational problem that is assumed to be hard. The practical value of a 
security proof depends on various factors: 


* How well-studied is Q? Some branches of cryptography, for example, some pairing-based 
constructions, rely on rather complex and exotic underlying problems that are assumed to 


be hard (but might not be) [KM1o]. 


How tight is the reduction of Q to P? A security proof may only show that if P can be 
solved in time T, the underlying problem Q can be solved (using the hypothetical A) in 
time, e.g., f(T) = T2. In practice, this might mean that for P to be secure, it needs to be 
deployed with a much larger key size or security parameter than Q to be secure. 


What other assumptions are used in the reduction? A common and useful but somewhat 
controversial assumption is the Random Oracle Model (ROM) [BRg3], where the usage of 
hash functions in a protocol is replaced with queries to a black box (called the Random 
Oracle), which is effectively a trusted third party that returns a truly random value for each 
input. Subsequent queries to the Random Oracle with the same value return the same result. 
While many consider ROM a practical assumption [KM15}/BR93], it has been shown that 
there exist carefully constructed protocols that are secure under the ROM, but are insecure 
with any concrete hash function [CGHog]. It is an open question whether this result carries 
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over to practical protocols, or just certain classes of artificially constructed protocols of 
theoretical interest. 


Furthermore, a provably secure protocol does not always lend itself easily to a secure implemen- 

tation, since side channels and fault injection attacks are usually not modeled. 

Finally, the security properties stated might not be sufficient or complete for the application. 
For our purposes, we focus on game-based provable security as 


opposed to simulation-based provable security |GMR89} Lin17], which is another approach to 
provable security typically used for zero-knowledge proofs and secure multiparty computation 


protocols. 


3.311 Algorithms, Oracles and Games 


In order to analyze the security of a protocol, the protocol and its desired security properties 
against an adversary with specific capabilities must first be modeled formally. This part is 
independent of a concrete instantiation of the protocol; the protocol is only described on a 
syntactic level. 

The possible operations of a protocol (i.e., the protocol syntax) are abstractly defined as 
the signatures of algorithms. Later, the protocol will be instantiated by providing a concrete 
implementation (formally a program for a probabilistic Turing machine) of each algorithm. A 
typical public key signature scheme, for example, might consist of the following algorithms: 


* KeyGen(1*) > (sk, pk), a probabilistic algorithm which on input 1^ generates a fresh key 
pair consisting of secret key sk of length A and and the corresponding public key pk. Note 
that 1^ is the unary representation of af] 


* Sign(sk,m) ++ 9, an algorithm that signs the bit string m with secret key sk to output the 
signature c. 


e Verify(pk,c, m) > b, an algorithm that determines whether c is a valid signature on m made 
with the secret key corresponding to the public key pk. It outputs the flag b € {0,1} to 
indicate whether the signature was valid (return value 1) or invalid (return value 0). 


The abstract syntax could be instantiated with various concrete signature protocols. 

In addition to the computational power given to the adversary, the capabilities of the adversary 
are defined via oracles. The oracles can be thought of as the APP] that is given to the adversary 
and allows the adversary to interact with the environment it is running in. Unlike the algorithms, 
which the adversary has free access to, the access to oracles is often restricted, and oracles can 
keep state that is not accessible directly to the adversary. Oracles typically allow the adversary to 
access information that it normally would not have direct access to, or to trigger operations in the 
environment running the protocol. 

Formally, oracles are an extension to the Turing machine that runs the adversary, which allow 
the adversary to submit queries to interact with the environment that is running the protocol. 

For a signature scheme, the adversary could be given access to an OSign oracle, which the 
adversary uses to make the system produce signatures, with secret keys that the adversary 
does not have direct access to. Different definitions of OSign lead to different capabilities of the 
adversary and thus to different security properties later on: 


* If the signing oracle OSign(m) is defined to take a message m and return a signature v on 
that message, the adversary gains the power to do chosen message attacks. 


“This formality ensures that the size of the input of the Turing machine program implementing the algorithm will be 
as least as big as the security parameter. Otherwise the run-time complexity cannot be directly expressed in relation to the 
size of the input tape. 

?[n the modern sense of application programming interface (API), where some system exposes a service with 
well-defined semantics. 
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* If OSign(-) was defined to return a pair (c, m) of a signature c on a random message m, the 
power of the adversary would be reduced to a known message attack. 


While oracles are used to describe the possible interactions with a system, it is more convenient 
to describe complex, multi-round interactions involving multiple parties as a special form of 
an algorithm, called an interactive protocol, that takes the identifiers of communicating parties 
and their (private) inputs as a parameter, and orchestrates the interaction between them. The 
adversary will then have an oracle to start an instance of that particular interactive protocol and (if 
desired by the security property being modeled) the ability to drop, modify or inject messages in 
the interaction. The typically more cumbersome alternative would be to introduce one algorithm 
and oracle for every individual interaction step. 

Security properties are defined via games, which are experiments that challenge the adversary 
to act in a way that would break the desired security property. Games usually consist multiple 
phases, starting with the setup phase where the challenger generates the parameters (such as 
encryption keys) for the game. In the subsequent query/response phase, the adversary is given 
some of the parameters (typically including public keys but excluding secrets) from the setup 
phase, and runs with access to oracles. The challenge] answers oracle queries during that phase. 
After the adversary’s program terminates, the challenger invokes the adversary again with a 
challenge. The adversary must now compute a final response to the challenger, sometimes with 
access to oracles. Depending on the answer, the challenger decides if the adversary wins the game 
or not, i.e., the game returns 0 if the adversary loses and 1 if the adversary wins. 

A game for the existential unforgeability of signatures could be formulated like this: 


Eee (1^): 

1. (sk, pk) +- KeyGen(1^) 

2. (c, m) — ,AOSign() (pk) 

(Run the adversary with input pk and access to the OSign oracle.) 

3. If the adversary has called OSign(-) with m as argument, return 0. 

4. Return Verify(pk, c, m). 
Here the adversary is run once, with access to the signing oracle. Depending on which definition 
of OSign is chosen, the game models existential unforgeability under chosen message attack 
(EUF-CMA) or existential unforgeability under known message attack (EUF-KMA) 


The following modification to the game would model selective unforgeability (SUF-CMA / 
SUF-KMA): 


Eg (1^): 

1.m+¢ A() 

2. (sk, pk) + KeyGen(1^) 

3. 0 APSi8) (pk, m) 

4. If the adversary has called OSign(-) with m as argument, return 0. 

5. Return Verify(pk, c, m). 
Here the adversary has to choose a message to forge a signature for before knowing the message 
verification key. 

After having defined the game, we can now define a security property based on the probability 
of the adversary winning the game: we say that a signature scheme is secure against existential 


unforgeability attacks if for every adversary .A (i.e., a polynomial-time probabilistic Turing 
machine program), the success probability 


Pr [Expos (14) = 1] 


3The challenger is conceptually the party or environment that runs the game/experiment. 
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of A in the EUF game is negligible (i.e., grows less fast with A than the inverse of any polynomial 
in A). 

Note that the EUF and SUF games are related in the following way: an adversary against the 
SUF game can be easily transformed into an adversary against the EUF game, while the converse 
does not necessarily hold. 

Often security properties are defined in terms of the advantage of the adversary. The advantage 
is a measure of how likely the adversary is to win against the real cryptographic protocol, 
compared to a perfectly secure version of the protocol. For example, let Exp T() be a game where 
the adversary has to guess the next bit in the output of a pseudo-random number generator 
(PRNG). The idealized functionality would be a real random number generator, where the 
adversary's chance of a correct guess is 1/2. Thus, the adversary's advantage is 


|Pr [ExpE O] - 1/2] 


Note that the definition of advantage depends on the game. The above definition, for example, 
would not work if the adversary had a way to “voluntarily” lose the game by querying an oracle 
in a forbidden way 


3.3312 Assumptions, Reductions and Game Hopping 


The goal of a security proof is to transform an attacker against the protocol under consideration 
into an attacker against the security of an underlying assumption. Typical examples for common 
assumptions might be: 


* the difficulty of the decisional/computational Diffie-Hellman problem (nicely described 
by [Bong8)) 
existential unforgeability under chosen message attack (EUF-CMA) of a signature scheme 


[GMR88] 


indistinguishability against chosen-plaintext attacks (IND-CPA) of a symmetric encryption 
algorithm [Bel+98 


To construct a reduction from an adversary A against P to an adversary against Q, it is 
necessary to specify a program R that both interacts as an adversary with the challenger for Q, 
but at the same time acts as a challenger for the adversary against P. Most importantly, R can 
chose how to respond to oracle queries from the adversary, as long as R faithfully simulates a 
challenger for P. The reduction must be efficient, i.e., R must still be a polynomial-time algorithm. 

A well-known example for a non-trivial reduction proof is the security proof of FDH-RSA 
signatures [Coroo]. 

In practice, reduction proofs are often complex and hard to verify. Game hopping has become 
a popular technique to manage the complexity of security proofs. The idea behind game hopping 
proofs is to make a sequence of small modifications starting from initial game, until you arrive at 
a game where the success probability for the adversary becomes obvious, for example, because 
the winning state for the adversary becomes unreachable in the code that defines the final game, 
or because all values the adversary can observe to make a decision are drawn from a truly random 
and uniform distribution. Each hop modifies the game in a way such that the success probability 
of game G, and game G,, +1 is negligibly close. 

Useful techniques for hops are, for example: 


* Bridging hops, where the game is syntactically changed but remains semantically equivalent, 
i.e., Pr [Gn = 1] = Pr [G, = 1]. 


e [ndistinguishability hops, where some distribution is changed in a way that an adversary 
that could distinguish between two adjacent games could be turned into an adversary that 
distinguishes the two distributions. If the success probability to distinguish between those 
two distributions is e, then |Pr [G,, = 1] — Pr [Gn = 1]| < e 
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* Hops based on small failure events. Here adjacent games proceed identically, until in one 
of the games a detectable failure event F (such as an adversary visibly forging a signature) 
occurs. Both games most proceed the same if F does not occur. Then it is easy to show 
[Shoog] that |Pr [Gn = 1] — Pr [Gn = 1]| < Pr [F] 


A tutorial introduction to game hopping is given by Shoup [Shoo4 , while a more formal 
treatment with a focus on “games as code” can be found in [BRo6]. A version of the FDH-RSA 
security proof based on game hopping was generated with an automated theorem prover by 
Blanchet and Pointcheval [BPo6]. 


3.1.3 Notation 


We prefix public and secret keys with pk and sk, and write x & Sto randomly select an element 
x from the set S with uniform probability. 


3.2 Model and Syntax for Taler 


We consider a payment system with a single, static exchange and multiple, dynamically created 
customers and merchants. The subset of the full Taler protocol that we model includes with- 
drawing digital coins, spending them with merchants and subsequently depositing them at the 
exchange, as well as obtaining unlinkable change for partially spent coins with an online “refresh” 
protocol. 

The exchange offers digital coins in multiple denominations, and every denomination has an 
associated financial value; this mapping is not chosen by the adversary but is a system parameter. 
We mostly ignore the denomination values here, including their impact on anonymity, in keeping 
with existing literature [PST 17]. For anonymity, we believe this amounts to assuming 
that all customers have similar financial behavior. We note logarithmic storage, computation and 
bandwidth demands denominations distributed by powers of a fixed constant, like two. 

We do not model fees taken by the exchange. Reserved] are also omitted. Instead of maintain- 
ing a reserve balance, withdrawals of different denominations are tracked, effectively assuming 
every customer has unlimited funds. 

Coins can be partially spent by specifying a fraction 0 « f < 1 of the total value associated 
with the coin's denomination. Unlinkable change below the smallest denomination cannot be 
given. In practice the unspendable, residual value should be seen as an additional fee charged by 
the exchange. 

Spending multiple coins is modeled non-atomically: to spend (fractions of) multiple coins, 
they must be spent one-by-one. The individual spend/deposit operations are correlated by 
a unique identifier for the transaction. In practice, this identifier is the hash transactionld — 
H(contractTerms) of the contract terms] Contract terms include a nonce to make them unique, 
that merchant and customer agreed upon. Note that this transaction identifier and the correlation 
between multiple spend operations for one payment need not be disclosed to the exchange 
(it might, however, be necessary to reveal during a detailed tax audit of the merchant): When 
spending the i-th coin for the transaction with the identifier transactionld, messages to the exchange 
would only contain H(i||transactionld). This is preferable for merchants that might not want to 
disclose to the exchange the individual prices of products they sell to customers, but only the 
total transaction volume over time. For simplicity, we do not include this extra feature in our 
model. 

Our system model tracks the total amount (= financial value) of coins withdrawn by each 
customer. Customers are identified by their public key pkCustomer. Every customer’s wallet 
keeps track of the following data: 


“Reserve” is Taler's terminology for funds submitted to the exchange that can be converted to digital coins. 
5The contract terms are a digital representation of an individual offer for a certain product or service the merchant 
sells for a certain price. 
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* wallet[pkCustomer] contains sets of the customer's coin records, which individually consist 
of the coin key pair, denomination and exchange's signature. 


e acceptedContracts|pkCustomer] contains the sets of transaction identifiers accepted by the 
customer during spending operations, together with coins spent for it and their contributions 
0 < f < 1. 


* withdrawlds[pkCustomer] contains the withdraw identifiers of all withdraw operations that 
were created for this customer. 


* refreshlds|pkCustomer] contains the refresh identifiers of all refresh operations that were 
created for this customer. 


The exchange in our model keeps track of the following data: 


* withdrawn [pkCustomer] contains the total amount withdrawn by each customer, i.e., the sum 
of the financial value of the denominations for all coins that were withdrawn by pkCustomer. 


* The overspending database of the exchange is modeled by deposited[pkCoin] and refreshed pkCoin], 
which record deposit and refresh operations respectively on each coin. Note that since 
partial deposits and multiple refreshes to smaller denominations are possible, one deposit 
and multiple refresh operations can be recorded for a single coin. 


We say that a coin is fresh if it appears in neither the deposited or refreshed lists nor in 


acceptedContracts. We say that a coin is being overspent if recording an operation in deposited 


or 


refreshed would cause the total spent value from both lists to exceed the value of the coin's 


denomination. Note that the adversary does not have direct read or write access to these values; 
instead the adversary needs to use the oracles (defined later) to interact with the system. 


We parameterize our system with two security parameters: The general security parameter A, 


and the refresh security parameter x. While A determines the length of keys and thus the security 
level, using a larger x will only decrease the success chance of malicious merchants conspiring 
with customers to obtain unreported (and thus untaxable) income. 


3.23 Algorithms 


The Taler e-cash scheme is modeled by the following probabilistid| polynomial-time algorithms 
and interactive protocols. The notation P(Xj,...,Xn) stands for a party P € {€,C, M} (Exchange, 
Customer and Merchant respectively) in an interactive protocol, with X4,..., Xn being the (possi- 
bly private) inputs contributed by the party to the protocol. Interactive protocols can access the 
state maintained by party P. 


While the adversary can freely execute the interactive protocols by creating their own parties, 


the adversary is not given direct access to the private data of parties maintained by the challenger 


in 


the security games we define later. 


e ExchangeKeygen(1^,1*, 9) ++ (sksE, pksE): Algorithm executed to generate keys for the 
exchange, with general security parameter A and refresh security parameter x, both given 
as unary numbers. The denomination specification D = dy,...,d is a finite sequence of 
positive rational numbers that defines the financial value of each generated denomination 
key pair. We henceforth use D to refer to some appropriate denomination specification, but 
our analysis is independent of a particular choice of 2. 

The algorithm generates the exchange's master signing key pair (skESig, pkESig) and de- 
nomination secret and public keys (skDi;,...,skD;), (pkD;,...,pkD,,). We write D(pkD;), 
where D : {pkD;} — 2 to look up the financial value of denomination pkD;. 

We collectively refer to the exchange's secrets by sksE and to the exchange's public keys 
together with D by pksE. 


Our Taler instantiations are not necessarily probabilistic (except, e.g., key generation), but we do not want to prohibit 


this for other instantiations 
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CustomerKeygen(1^,1*) ++ (skCustomer, pkCustomer): Key generation algorithm for cus- 
tomers with security parameters À and x. 


MerchantKeygen(1^,1*) ++ (skMerchant, pkMerchant): Key generation algorithm for mer- 
chants. Typically the same as CustomerKeygen. 


WithdrawRequest(£ (sksE, pkCustomer), C (skCustomer, pksE, pkD)) — (Tw, wid): Interactive 
protocol between the exchange and a customer that initiates withdrawing a single coin of a 
particular denomination. 


The customer obtains a withdraw identifier wid from the protocol execution and stores it in 
withdrawlds|pkCustomer]. 


The WithdrawRequest protocol only initiates a withdrawal. The coin is only obtained and 
stored in the customer’s wallet by executing the WithdrawPickup protocol on the withdraw 
identifier wid. 


The customer and exchange persistently store additional state (if required by the instantia- 
tion) such that the customer can use WithdrawPickup to complete withdrawal or to complete 
a previously interrupted or unfinished withdrawal. 


Returns a protocol transcript Twp of all messages exchanged between the exchange and 
customer, as well as the withdraw identifier wid. 


WithdrawPickup(£ (sksE, pkCustomer), C (skCustomer, pksE, wid)) ++ (Twp, coin): Interactive 
protocol between the exchange and a customer to obtain the coin from a withdraw operation 
started with WithdrawRequest, identified by the withdraw identifier wid. 


The first time WithdrawPickup is run with a particular withdraw identifier wid, the exchange 
increments withdrawn|pkCustomer] by D(pkD), where pkD is the denomination requested in 
the corresponding WithdrawRequest execution. How exactly pkD is restored depends on the 
particular instantiation. 


The resulting coin 


coin — (skCoin, pkCoin, pkD, coinCert), 


consisting of secret key skCoin, public key pkCoin, denomination public key pkD and certifi- 
cate coinCert from the exchange, is stored in the customers wallet wallet|pkCustomer]. 


Executing the WithdrawPickup protocol multiple times with the same customer and the 
same withdraw identifier does not result in any change of the customer's withdraw balance 
withdrawn pkCustomer], and results in (re-)adding the same coin to the customer's wallet. 


Returns a protocol transcript Twp of all messages exchanged between the exchange and 


customer. 


Spend(transactionld, f, coin, pkMerchant) ++ depositPermission: Algorithm to produce and 
sign a deposit permission depositPermission for a coin under a particular transaction identifier. 
The fraction 0 < f < 1 determines the fraction of the coin's initial value that will be spent. 


The contents of the deposit permission depend on the instantiation, but it must be possible 
to derive the public coin identifier pkCoin from them. 

Deposit(€ (sksE, pkMerchant), M (skMerchant, pksE, depositPermission)) ++ Tp: Interactive pro- 
tocol between the exchange and a merchant. 


From the deposit permission we obtain the pkCoin of the coin to be deposited. If pkCoin is 
being overspent, the protocol is aborted with an error message to the merchant. 


On success, we add depositPermission to deposited pkCoin]. 


Returns a protocol transcript 7p of all messages exchanged between the exchange and 
merchant. 
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* RefreshRequest(£ (sksE), C (pkCustomer, pksE, coing, pkD,,)) — (Trp, rid) Interactive protocol 
between exchange and customer that initiates a refresh of coing. Together with RefreshPickup, 
it allows the customer to convert D(pkD,,) of the remaining value on coin 


coing = (skCoing, pkCoing, pkDo, coinCertg) 


into a new, unlinkable coin coin, of denomination pkD,,. 


Multiple refreshes on the same coin are allowed, but each run subtracts the respective 
financial value of coin, from the remaining value of coing. 


The customer only records the refresh operation identifier rid in refreshlds|pkCustomer], but 
does not yet obtain the new coin. To obtain the new coin, RefreshPickup must be used. 


Returns the protocol transcript Tkg and a refresh identifier rid. 


RefreshPickup(€ (sksE, pkCustomer), C (skCustomer, pksE, rid)) — (mp, coin;): Interactive pro- 
tocol between exchange and customer to obtain the new coin for a refresh operation 
previously started with RefreshRequest, identified by the refresh identifier rid. 


The exchange learns the target denomination pkD,, and signed source coin (pkCoing, pkDg, coinCertg). 
If the source coin is invalid, the exchange aborts the protocol. 


The first time RefreshPickup is run for a particular refresh identifier, the exchange records a 
refresh operation of value D(pkD,,) in refreshed[pkCoing]. If pkCoing is being overspent, the 
refresh operation is not recorded in refreshed|[pkCoing|, the exchange sends the customer the 
protocol transcript of the previous deposits and refreshes and aborts the protocol. 


If the customer C plays honestly in RefreshRequest and RefreshPickup, the unlinkable coin 
coin, they obtain as change will be stored in their wallet wallet[pkCustomer]. If C is caught 
playing dishonestly, the RefreshPickup protocol aborts. 


An honest customer must be able to repeat a RefreshPickup with the same rid multiple times 
and (re-)obtain the same coin, even if previous RefreshPickup executions were aborted. 


Returns a protocol transcript Trp. 


Link(£ (sksE), C (skCustomer, pksE, coing)) — (T, (coiny,...,coiny)): Interactive protocol be- 
tween exchange and customer. If coing is a coin that was refreshed, the customer can 
recompute all the coins obtained from previous refreshes on coing, with data obtained 
from the exchange during the protocol. These coins are added to the customer's wallet 
wallet[pkCustomer] and returned together with the protocol transcript. 


3.2.2 Oracles 


We now specify how the adversary can interact with the system by defining oracles. Oracles 
are queried by the adversary, and upon a query the challenger will act according to the oracle's 
specification. Note that the adversary for the different security games is run with specific oracles, 
and does not necessarily have access to all oracles simultaneously. 

We refer to customers in the parameters to an oracle query simply by their public key. The 
adversary needs the ability to refer to coins to trigger operations such as spending and refresh, 
but to model anonymity we cannot give the adversary access to the coins' public keys directly. 
Therefore we allow the adversary to use the (successful) transcripts of the withdraw, refresh and 
link protocols to indirectly refer to coins. We refer to this as a coin handle H. Since the execution 
of a link protocol results in a transcript 7 that can contain multiple coins, the adversary needs to 
select a particular coin from the transcript via the index i as H = (7, i). The respective oracle 
tries to find the coin that resulted from the transcript given by the adversary. If the transcript has 
not been seen before in the execution of a link, refresh or withdraw protocol; or the index for a 
link transcript is invalid, the oracle returns an error to the adversary. 

In oracles that trigger the execution of one of the interactive protocols defined in Section 
we give the adversary the ability to actively control the communication channels between 
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the exchange, customers and merchants; i.e., the adversary can effectively record, drop, modify 
and inject messages during the execution of the interactive protocol. Note that this allows the 
adversary to leave the execution of an interactive protocol in an unfinished state, where one or 
more parties are still waiting for messages. We use Z to refer to a handle to interactive protocols 
where the adversary can send and receive messages. 


OAddCustomer() ++ pkCustomer: Generates a key pair (skCustomer, pkCustomer) using the 
CustomerKeygen algorithm, and sets 


withdrawn|pkCustomer| := 0 
acceptedContracts[pkCustomer] :— { } 
wallet[pkCustomer] := { } 
withdrawlds[pkCustomer] := [| 
refreshlds[pkCustomer] := 1). 


Returns the public key of the newly created customer. 


OAddMerchant() +» pkMerchant: Generate a key pair (skMerchant, pkMerchant) using the 
MerchantKeygen algorithm. 


Returns the public key of the newly created merchant. 


OSendMessage(Z, Pi, P», m) ++ (): Send message m on the channel from party P; to party 
P» in the execution of interactive protocol Z. The oracle does not have a return value. 


OReceiveMessage(Z, P1, P2) — m: Read message m in the channel from party Pj to party P» 
in the execution of interactive protocol Z. If no message is queued in the channel, return 
m — 1. 


OWithdrawRequest(pkCustomer, pkD) — Z: Triggers the execution of the WithdrawRequest 
protocol. the adversary full control of the communication channels between customer and 
exchange. 


OWithdrawPickup(pkCustomer, pkD, T) ++ T: Triggers the execution of the WithdrawPickup 
protocol, additionally giving the adversary full control of the communication channels 
between customer and exchange. 


The customer and withdraw identifier wid are obtained from the WithdrawRequest transcript 


Ts 


ORefreshRequest(H, pkD) — Z: Triggers the execution of the RefreshRequest protocol with 
the coin identified by coin handle H, additionally giving the adversary full control over the 
communication channels between customer and exchange. 


ORefreshPickup(7 ) ++ T: Triggers the execution of the RefreshPickup protocol, where the 
customer and refresh identifier rid are obtained from the RefreshRequest protocol transcript 


T. 


Additionally gives the adversary full control over the communication channels between 
customer and exchange. 


OLink(H) — T: Triggers the execution of the Link protocol for the coin referenced by handle 
H, additionally giving the adversary full control over the communication channels between 
customer and exchange. 


OSpend(transactionld, pkCustomer, H, pkMerchant) +» depositPermission: Makes a customer 
sign a deposit permission over a coin identified by handle H. Returns the deposit permission 
on success, or L if H is not a coin handle that identifies a coin. 
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Note that OSpend can be used to generate deposit permissions that, when deposited, would 
result in an error due to overspending 


Adds (transactionld, depositPermission) to acceptedContracts[pkCustomer]. 


OShare(H, pkCustomer) > (): Shares a coin (identified by handle H) with the customer 
identified by pkCustomer, i.e., puts the coin identified by H into wallet[pkC ustomer]. Intended 
to be used by the adversary in attempts to violate income transparency. Does not have a 
return value. 


Note that this trivially violates anonymity (by sharing with a corrupted customer), thus the 
usage must be restricted in some games. 


OCorruptCustomer(pkCustomer) > 
(skCustomer, wallet[pkCustomer], acceptedContracts|pkCustomer], 
refreshlds|pkCustomer], withdrawlds[pkCustomer]): 


Used by the adversary to corrupt a customer, giving the adversary access to the customer's 
secret key, wallet, withdraw /refresh identifiers and accepted contracts. 


Permanently marks the customer as corrupted. There is nothing "special" about corrupted 
customers, other than that the adversary has used OCorruptCustomer on them in the past. 
The adversary cannot modify corrupted customer's wallets directly, and must use the oracle 
again to obtain an updated view on the corrupted customer's private data. 


ODeposit(depositPermission) — Z: Triggers the execution of the Deposit protocol, addition- 
ally giving the adversary full control over the communication channels between merchant 
and exchange. 


Returns an error if the deposit permission is addressed to a merchant that was not registered 
with OAddMerchant. 


This oracle does not give the adversary new information, but is used to model the situation 
where there might be multiple conflicting deposit permissions generated via Spend, but only 
a limited number can be deposited. 


We write OTALER for the set of all the oracles we just defined, and ONOSHARE := OTALER — 
OShare for all oracles except the share oracle. 

The exchange does not need to be corrupted with an oracle. A corrupted exchange is modeled 
by giving the adversary the appropriate oracles and the exchange secret key from the exchange 
key generation. 

If the adversary determines the exchange's secret key during the setup, invoking OWithdrawRequest, 
OWithdrawPickup, ORefreshRequest, ORefreshPickup or OLink can be seen as the adversary play- 
ing the exchange. Since the adversary is an active man-in-the-middle in these oracles, it can drop 
messages to the simulated exchange and make up its own response. If the adversary calls these 
oracles with a corrupted customer, the adversary plays as the customer. 


3.3 Games 


We now define four security games (anonymity, conservation, unforgeability and income trans- 
parency) that are later used to define the security properties for Taler. Similar to we 
assume that the game and adversary terminate in finite time, and thus random choices made by 
the challenger and adversary can be taken from a finite sample space. 

All games except income transparency return 1 to indicate that the adversary has won and 0 
to indicate that the adversary has lost. The income transparency game returns 0 if the adversary 
has lost, and a positive "laundering ratio" if the adversary won. 
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3.31 Anonymity 


Intuitively, an adversary A (controlling the exchange and merchants) wins the anonymity game if 
they have a non-negligible advantage in correlating spending operations with the withdrawal or 
refresh operations that created a coin used in the spending operation. 

Let b be the bit that will determine the mapping between customers and spend operations, 
which the adversary must guess. 

We define a helper procedure 


Refresh(€ (sksE), C (pkCustomer, pksE, coing)) + AR 


that refreshes the whole remaining amount on coing with repeated application of RefreshRequest 
and RefreshPickup using the smallest possible set of target denominations, and returns all protocol 
transcripts in 5. 


Expor e 38 y 
. (sksE, pksE, skM, pkM) — A() 


1 
2. (pkCustomerg, pkCustomery, transactionldo, transactionld;, f) «— .AONoSnanr() 
3 


. Select distinct fresh coins 


coing € wallet[pkCustomerg] 


coin; € wallet[pkCustomer;] 


Return 0 if either pkCustomerg or pkCustomer; are not registered customers with sufficient fresh 
coins. 


4. Fori € {0,1} run 


dp; «— Spend(transactionld;, f, coin;—p, pkM) 
Deposit(.A(), M (skM, pksE, dp;)) 
R; — Refresh(.A(), C(pkCustomer;, pksE, coin; .;)) 


5. be AONOSHARE (Ro, 94) 


6. Return 0 if OSpend was used by the adversary on the coin handles for coing or coin; or 
OCorruptCustomer was used on pkCustomerg or pkCustomer;. 


7. If b = b' return 1, otherwise return 0. 


Note that unlike some other anonymity games defined in the literature (such as [PST17]), our 
anonymity game always lets both customers spend in order to avoid having to hide the missing 
coin in one customer's wallet from the adversary. 


3.3.2. Conservation 


The adversary wins the conservation game if it can bring an honest customer in a situation where 
the spendable financial value left in the user's wallet plus the value spent for transactions known 
to the customer is less than the value withdrawn by the same customer through by the exchange. 

In practice, this property is necessary to guarantee that aborted or partially completed 
withdrawals, payments or refreshes, as well as other (transient) misbehavior from the exchange or 
merchant do not result in the customer losing money. 


pu ep 15): 
1. (sksE, pksE) — ExchangeKeygen(1^, 1*, M) 
2. pkCustomer + AONOSHARE (pksE) 
3. Return 0 if pkCustomer is a corrupted user. 
4- 


Run WithdrawPickup for each withdraw identifier wid and RefreshPickup for each refresh iden- 
tifier rid that the user has recorded in withdrawlds and refreshlds. Run Deposit for all deposit 
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permissions in acceptedContracts. 


5. Let vc be the total financial value left on valid coins in wallet[pkCustomer], i.e., the denominated 
values minus the spend/refresh operations recorded in the exchange’s database. Let vs be the 
total financial value of contracts in acceptedContracts|pkCustomer]. 


6. Return 1 if withdrawn[pkCustomer] > vc + vs. 


Hence we ensure that: 


* ifa coin was spent, it was spent for a contract that the customer knows about, i.e., in practice 
the customer could prove that they "own" what they paid for, 


* if a coin was refreshed, the customer "owns" the resulting coins, even if the operation was 
aborted, and 


* if the customer withdraws, they can always obtain a coin whenever the exchange accounted 
for a withdrawal, even when protocol executions are intermittently aborted. 


Note that we do not give the adversary access to the OShare oracle, since that would trivially 
allow the adversary to win the conservation game. In practice, conservation only holds for 
customers that do not share coins with parties that they do not fully trust. 


3.3.3 Unforgeability 


Intuitively, adversarial customers win if they can obtain more valid coins than they legitimately 
withdraw. 


Exp E (14,1); 
1. (skE, pkE) «- ExchangeKeygen() 
2. (Co,...,Cp) E AOA“ (pkExchange) 
3. Return 0 if any C; is not of the form (skCoin, pkCoin, pkD, coinCert) or any coinCert is not a valid 
signature by pkD on the respective pkCoin. 


4. Return 1 if the sum of the unspent value of valid coins in Co . . . , C; exceeds the amount withdrawn 
by corrupted customers, return 0 otherwise. 


3.3.4 Income Transparency 


Intuitively, the adversary wins if coins are in exclusive control of corrupted customers, but the 
exchange has no record of withdrawal or spending for them. This presumes that the adversary 
cannot delete from non-corrupted customer’s wallets, even though it can use oracles to force 
protocol interactions of non-corrupted customers. 

For practical e-cash systems, income transparency disincentivizes the emergence of “black mar- 
kets” among mutually distrusting customers, where currency circulates without the transactions 
being visible. This is in contrast to some other proposed e-cash systems and cryptocurrencies, 
where disintermediation is an explicit goal. The Link protocol introduces the threat of losing 
exclusive control of coins (despite having the option to refresh them) that were received without 
being visible as income to the exchange. 


Eaptcime (12. 1"): 

1. (skE, pkE) «- ExchangeKeygen() 

2. (coiny,...,coing) — APA (pkExchange) 
(The coin; must be coins, including secret key and signature by the denomination, for the 
adversary to win. However these coins need not be present in any honest or corrupted customer’s 
wallet.) 

3. Augment the wallets of all non-corrupted customers with their transitive closure using the Link 
protocol. Mark all remaining value on coins in wallets of non-corrupted customers as spent in 
the exchange’s database. 
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4. Let L denote the sum of unspent value on valid coins in (coiny,... coing), after accounting for 
the previous update of the exchange's database. Also let w' be the sum of coins withdrawn by 
corrupted customers. Then p :— L — w' gives the adversary's untaxed income. 

5. Let w be the sum of coins withdrawn by non-corrupted customers, and s be the value marked as 
spent by non-corrupted customers, so that b :— w — s gives the coins lost during refresh, that is 
the losses incurred attempting to hide income. 

6. If b+ p # 0, return b ie., the laundering ratio for attempting to obtain untaxed income. 
Otherwise return 0. 


3.4 Security Definitions 


We now give security definitions based upon the games defined in the previous section. Recall 
that A is the general security parameter, and x is the security parameter for income transparency. 
A polynomial-time adversary is implied to be polynimial in A + x. 


Definition 3.4.1 (Anonymity). We say that an e-cash scheme satisfies anonymity if the success 
probability Pr E = 10,1) : Exp%®" (1^,1*,b) = 1] of the anonymity game is negligibly close to 
1/2 for any polynomial-time adversary A. 


Definition 3.4.2 (Conservation). We say that an e-cash scheme satisfies conservation if the success 
probability Pr [Exp (14, 1%) = 1] of the conservation game is negligible for any polynomial- 
time adversary A. 


Definition 3.4.3 (Unforgeability). We say that an e-cash scheme satisfies unforgeability if the 
success probability Pr [Exp SOS em 1] of the unforgeability game is negligible for any 


polynomial-time adversary A. 


Definition 3.4.4 (Strong Income Transparency). We say that an e-cash scheme satisfies strong income 


income 


transparency if the success probability Pr [Exp “A Hn deis o] for the income transparency game 
is negligible for any polynomial-time adversary A. 


The adversary is said to win one execution of the strong income transparency game if the 
game's return value is non-zero, i.e., there was at least one successful attempt to obtain untaxed 
income. 


Definition 3.4.5 (Weak Income Transparency). We say that an e-cash scheme satisfies weak income 
transparency if, for any polynomial-time adversary A, the return value of the income transparency 


game satisfies 
—— 1 
E [Expte 5,15) E (3.1) 


In (3-1), the expectation runs over any probability space used by the adversary and challenger. 


For some instantiations, e.g., ones based on zero-knowledge proofs, x might be a security 
parameter in the traditional sense. However for an e-cash scheme to be useful in practice, 
the adversary does not need to have only negligible success probability to win the income 
transparency game. It suffices that the financial losses of the adversary in the game are a deterrent, 
after all our purpose of the game is to characterize tax evasion. 

Taler does not fulfill strong income transparency, since for Taler x must be a small cut- 
and-choose parameter, as the complexity of our cut-and-choose protocol grows linearly with 
x. Instead we show that Taler satisfies weak income transparency, which is a statement about 
the adversary's financial loss when winning the game instead of the winning probability. The 
return-on-investment (represented by the game's return value) is bounded by 1/x. 

We still characterize strong income transparency, since it might be useful for other instantia- 
tions that provide more absolute guarantees. 
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Instantiation 


We give an instantiation of our protocol syntax that is generic over a blind signature scheme, 
a signature scheme, a combined signature scheme / key exchange, a collision-resistant hash 
function and a pseudo-random function family (PRF). 


3.5.1 Generic Instantiation 


Let BLINDSIGN be a blind signature scheme with the following syntax, where the party S is the 
signer and R is the signature requester: 


KeyGengs (1^) — (sk, pk) is the key generation algorithm for the signer of the blind signature 
protocol. 


Blindgs (S (sk), R(pk,m)) ++ (m,r) is a possibly interactive protocol to blind a message m 
that is to be signed later. The result is a blinded message m and a residual r that allows to 
unblind a blinded signature on m made by sk. 


Signgs (S (sk), R(M)) > v is an algorithm to sign a blinded message m. The result 7 is a 
blinded signature that must be unblinded using the r returned from the corresponding 
blinding operation before verification. 


UnblindSiggs (r, m, 7) > c is an algorithm to unblind a blinded signature. 


Verifygs (pk, m, 0) ++ b is an algorithm to check the validity of an unblinded blind signature. 
Returns 1 if the signature v was valid for m and 0 otherwise. 


Note that this syntax excludes some blind signature protocols, such as those with interac- 
tive/probabilistic verification or those without a “blinding factor", where the Blindgs and Signgs 
and UnblindSiggs would be merged into one interactive signing protocol. Such blind signature 
protocols have already been used to construct e-cash |CHLos]. 

We require the following two security properties for BLINDSIGN: 


blindness: It should be computationally infeasible for a malicious signer to decide which of 
two messages has been signed first in two executions with an honest user. The corresponding 


game can be defined as in Abe and Okamoto [AOo0| , With the additional enhancement that 
the adversary generates the signing key [SU17]. 


unforgeability: An adversary that requests k signatures with Signgs is unable to produce 
k + 1 valid signatures with non-negligible probability. 


For more generalized notions of the security of blind signatures see, e.g., [FSo9}|/SU17]. 
Let CorNSIGNKx be combination of a signature scheme and key exchange protocol: 


KeyGenSeccsy (1^) ++ sk is a secret key generation algorithm. 
KeyGenPubcsx (sk) > pk produces the corresponding public key. 
Signcsk (sk, m) ++ c produces a signature 7 over message m. 


Verifycsx (pk, m, g) ++ b is a signature verification algorithm. Returns 1 if the signature c is 
a valid signature on m by pk, and 0 otherwise. 


Kxcsk(sk1, pk2) + x is a key exchange algorithm that computes the shared secret x from 
secret key sky and public key pk». 


We occasionally need these key generation algorithms separately, but we usually combine 
them into KeyGencsk (1^) ++ (sk, pk). 
We require the following security properties to hold for CorNSIGNKx: 
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unforgeability: The signature scheme (KeyGencsx, Signcsx, Verifycsk) must satisfy existential 
unforgeability under chosen message attacks (EUF-CMA). 


key exchange completeness: Any probabilistic polynomial-time adversary has only negligible 
chance to find a degenerate key pair (sk,4,pk,) such that for some honestly generated 
key pair (skg, pkg) +- KeyGencsk(1*) the key exchange fails, that is Kexcsx(ska, pkg) Æ 
Kexcsx (skg, pk), while the adversary can still produce a pair (m, 7) such that Verifygs (pka, m, 0) = 


key exchange security: The output of Kxcsx must be computationally indistinguishable from 
a random shared secret of the same length, for inputs that have been generated with 
KeyGencs K- 


Let SIGN = (KeyGeng, Signs, Verifys) be a signature scheme that satisfies selective unforgeability 
under chosen message attacks (SUF-CMA). 

Let PRF be a pseudo-random function family and H : {0,1}* > {0,1} a collision-resistant 
hash function. 

Using these primitives, we now instantiate the syntax of our income-transparent e-cash scheme: 


ExchangeKeygen(1^, 1*, D): 
Generate the exchange's signing key pair skESig + KeyGeng (1^). 


For each element in the sequence D = d;,..., dn, generate denomination key pair (skD;, pkD;) + 
KeyGengs (1^). 


CustomerKeygen(1^, 1*): Return key pair KeyGens (1^). 
MerchantKeygen(1^, 1*): Return key pair KeyGeng (1^). 


WithdrawRequest(£ (sksE, pkCustomer), C (skCustomer, pksE, pkD)): 


Let skD be the exchange's denomination secret key corresponding to pkD. 


1. C generates coin key pair (skCoin, pkCoin) +- KeyGencsk (1^) 
2. C runs (m,r) — Blindcsk (€ (skCoin), C (m)) with the exchange 


The withdraw identifier is then 
wid := (skCoin, pkCoin, m,r) 
WithdrawPickup(£ (sksE, pkCustomer), C (skCustomer, pksE, wid)): 
The customer looks up skCoin, pkCoin, pkD m and r via the withdraw identifier wid. 


1. C runs F + Signgs(£ (skD),C(m)) with the exchange 


2. C unblinds the signature 7 — UnblindSiggs (c, r, m) and stores the coin (skCoin, pkCoin, pkD, 7) 
in their wallet. 


Spend(transactionld, f, coin, pkMerchant): Let (skCoin, pkCoin, pkD, 7c) :— coin. The deposit 
permission is computed as 


depositPermission :— (pkCoin, op, m), 
where 


m :— (pkCoin, pkD, sigmac, transactionld, f, pkMerchant) 
gp + Signcsk (skCoin, m). 
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Deposit (€ (sksE, pkMerchant), M (skMerchant, pksE, depositPermission) ): The merchant sends 
depositPermission to the exchange. 


The exchange checks that the deposit permission is well-formed and sets 


pkCoin, pkD, ec, Cp, transactionld, f, pk Merchant) ) := depositPermission 
C 


The exchange checks the signature on the deposit permission and the validity of the coin 
with 

bı := Verifycsx (pkCoin, op, m) 

b; :— Verifygs(pkD, ec, pkCoin) 


and aborts of b4 = 0 or bp = 0. 
The exchange aborts if spending f would result in overspending pkCoin based on existing 
deposit/refresh records, and otherwise marks pkCoin as spent for D(pkD). 
RefreshRequest(€ (sksE, pkCustomer), C (skCustomer, pksE, coing, pkD,,)): 
Let skD,, be the secret key corresponding to pkD,. 
We write 

Blinds (S (sk, skESig), R(R, skR, pk, m)) > (m,r, Tg.) 


for a modified version of Blindgs where the signature requester R takes all randomness 
from the sequence (PRF(R, "blind" ||n)),.o, the messages from the exchange are recorded 
in transcript 75., all messages sent by R are signed with skR and all messages sent by S are 
signed with skESig. 


Furthermore, we write 
KeyGenécx(R,1*) > (sk, pk) 
for a modified version of the key generation algorithm that takes randomness from the 


sequence (PRF(R, "key" ||n)),0- 


For each i € {1,...,«}, the customer 


1. generates seed s; he Tous 
2. generates transfer key pair (t;,T;) +- KeyGené¢x(s;,1*) 
3. computes transfer secret x; +- Kx(t;, pkCoing) 
4. computes coin key pair (skCoin;, pkCoin;) +- KeyGenécx (x;, 1^) 
5. and executes the modified blinding protocol 
(mj, ri, T(,;)) €- Blindgs(£ (skDu), C (xi, skCoing, pkD,,, pkCoin;)) 
with the exchange. 


The customer stores the refresh identifier 
rid :— (coing, pkD,, {si}, (i), {ri}, UT (ps) )- (3.2) 


RefreshPickup(€ (sksE, pkCustomer), C (skCustomer, pksE, rid)) — 7: The customer looks up 
the refresh identifier rid and recomputes the transfer key pairs, transfer secrets and new 
coin key pairs. 


Then customer sends the commitment 7t; = (pkCoino, pkD„, hc) together with signature 
sig, E Signcsx(skCoing, 711) to the exchange, where 

hr = H(Tı,. zk) 

hg = H(m, . N ., Tx) 

he := H(hr||hm) 
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The exchange checks the signature sig;, and aborts if invalid. Otherwise, depending on the 
commitment: 


1. If the exchange did not see 711 before, it marks pkCoing as spent for D(pkD,,), chooses 
a uniform random 0 < y < x, stores it, and sends this choice in a signed message 
(y, sig?) to the customer, where sig, — Signs (skESig, y). 


2. Otherwise, the exchange sends back the same 77, as it sent for the last equivalent 71. 
The customer checks if 712 differs from a previously received 71, for the same request 7ı, 


and aborts if such a conflicting response was found. Otherwise, the customer in response to 
7t? sends the reveal message 


7 = Try, Mey, (81,..., 84 1,8445, Sx) 
and signature 
sigy «— Signcsx(skCoing, (pkCoing, pkD,,, 7(p. ^), Ty My)) 
to the exchange. Note that sigy is not a signature over the full reveal message, but is 


primarily used in the linking protocol for checks by the customer. 


The exchange checks the signature sigy and then computes for i 4 y: 


(ti, T!) «- KeyGenësg (si, 1^) 
x; — Kx(ti, pkCoing) 
(skCoin/, pkCoin/) +- KeyGenzs, (x7, 1^) 
pr HT j. Tı Ty Ties Te) 
and simulates the blinding protocol with recorded transcripts (without signing each message, 
as indicated by the dot (-) instead of a signing secret key), obtaining 


m; ri, Ti) — Blind¿s(S(skD,,), R(x), -, pkD,,, skCoin;)) 


and finally 


/ 1 A 1 =/ 
hi := H(m,. .., Myy My T a. UT) 


c := H(hr||hm). 


Now the exchange checks if hc = họ, and aborts the protocol if the check fails. Otherwise, 
the exchange sends a message back to C that the commitment verification succeeded and 
includes the signature 

Ty := Signgs(€ (skD,), C (m4) ). 


As a last step, the customer obtains the signature c; on the new coin's public key pkCoin,, 
with 
Cy = UnblindSig(r,, pkCoin,,, 7). 


Thus, the new, unlinkable coin is coin, := (skCoin,, pkCoin,,, pkD,,, 0). 
Link(£ (sksE), C (skCustomer, pksE, coing)): The customer sends the public key pkCoing of 


coing to the exchange. 


For each completed refresh on pkCoing recorded in the exchange's database, the exchange 
sends the following data back to the customer: the signed commit message (sigı, 711), the 
transfer public key T}, the signature sigy, the blinded signature v», and the transcript 7(g..) 
of the customer's and exchange's messages during the Blind¿g protocol execution. 


The following logic is repeated by the customer for each response: 
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1. Verify the signatures (both from pkESig and pkCoing) on the transcript T(Be y abort 
otherwise. 


2. Verify that sig; is a valid signature on 7t; by pkCoing, abort otherwise. 


3. Re-compute the transfer secret and the new coin's key pair as 


Xy — Kxcsx(skCoing, Ty) 


(skCoin,, pkCoin.,) — KeyGencsy (x4, 1^). 


4. Simulate the blinding protocol with the message transcript received from the exchange 
to obtain (My, r^). 

5. Check that Verifycsx (pkCoing, pkD,,, skCoino, (7(g.. y), My), sig) indicates a valid signa- 
ture, abort otherwise. 

6. Unblind the signature to obtain 0, +- UnblindSig(r», pkCoin,, 7) 


7. (Re-)add the coin (skCoin,, pkCoin,,, pkD,,, 7) to the customer's wallet. 


3.5.2 Concrete Instantiation 


We now give a concrete instantiation that is used in the implementation of GNU Taler for the 
schemes BLINDSIGN, COINSIGNKx and SIGN. 

For BLINDSIGN, we use RSA-FDH blind signatures [BR96]. From the information- 
theoretic security of blinding, the computational blindness property follows directly. For the 
unforgeability property, we additionally rely on the RSA-KTI assumption as discussed in [Bel+o3]. 
Note that since the blinding step in RSA blind signatures is non-interactive, storage and verification 
of the transcript is omitted in refresh and link. 

We instantiate CorNSIGNKx with signatures and key exchange operations on elliptic curves in 
Edwards form, where the same key is used for signatures and the Diffie-Hellman key exchange 
operations. In practice, we use Ed25519 / Curve25519 for A = 256. We caution 
that some other elliptic curve key exchange implementation might not satisfy the completeness 
property that we require, due to the lack of complete addition laws. 

For SIGN, we use elliptic-curve signatures, concretely Ed25519. For the collision-resistant hash 


function H we use SHA-512 [H306] and HKDF [KE10] as a PRF. 


3.6 Proofs 


We now give proofs for the security properties defined in Section B.4|with the generic instantiation 
of Taler. 
3.6.1 Anonymity 
Theorem 1. Assuming 
* the blindness of BLINDSIGN, 
* the unforgeability and key exchange security of COINSIGNKx, and 
* the collision resistance of H, 
our instantiation satisfies anonymity. 


Proof. We give a proof via a sequence of games Go(b), Gı (b), G2(b), where Go(b) is the original 
anonymity game Exp%j'°"(14,1*, b). We show that the adversary can distinguish between subse- 
quent games with only negligible probability. Let e4c and exx be the advantage of an adversary 
for finding hash collisions and for breaking the security of the key exchange, respectively. 
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We define G4 by replacing the link oracle OLink with a modified version that behaves the same 
as OLink, unless the adversary responds with link data that did not occur in the transcript of a 
successful refresh operation, but despite of that still passes the customer’s verification. In that 
case, the game is aborted instead. 

Observe that in case this failure event happens, the adversary must have forged a sig- 
nature on sig; on values not signed by the customer, yielding an existential forgery. Thus, 
[Pr [Go = 1] — Pr [G, = 1]| is negligible. 

In Go, the refresh oracle is modified so that the customer responds with value drawn from 
a uniform random distribution Dı for the y-th commitment instead of using the key exchange 
function. We must handle the fact that y is chosen by the adversary after seeing the commitments, 
so the challenger first makes a guess y* and replaces only the y*-th commitment with a uniform 
random value. If the y chosen by the adversary does not match y*, then the challenger rewinds A 
to the point where the refresh oracle was called. Note that we only replace the one commitment 
that will not be opened to the adversary later. 

Since x < A and the security property of Kx guarantees that the adversary cannot distinguish 
the result of a key exchange from randomness, the runtime complexity of the challenger still stays 
polynomial in A. An adversary that could with high probability choose a y that would cause a 
rewind, could also distinguish randomness from the output of Kx. 

We now show that |Pr [G; = 1] — Pr [G2 = 1]| € exx by defining a distinguishing game G1~2 
for the key exchange as follows: 


Gi.2(b): 
1. If b = 0, set 


Do :— (A, B, Kex(a, B)) | (a, A) + KeyGen(1^), (b, B) - KeyGen(1?)). 
Otherwise, set 


D; := {(A,B,C) | (a, A) € KeyGen(1^), (b, B) — KeyGen(1^), C £ {1,...,24}}. 


2. Return Exp" (b, Dy) 


(Modified anonymity game where the y-th commitment in the refresh oracle is drawn 
uniformly from Dj (using rewinding). Technically, we need to draw from Dy on withdraw 
for the coin secret key, write it to a table, look it up on refresh and use the matching tuple, 
so that with b = 0 we perfectly simulate Gj.) 


Depending on the coin flip b, we either simulate G; or Gz perfectly for our adversary A 
against G;. At the same time b determines whether A receives the result of the key exchange or 
real randomness. Thus, [Pr [G4 = 1] — Pr [Gz = 1]| = exx is exactly the advantage of G1~2. 

We observe in G» that as x, is uniform random and not learned by the adversary, the 
generation of (skCoin^, pkCoin, ) and the execution of the blinding protocol is equivalent (under 
the PRF assumption) to using the randomized algorithms KeyGencsx and Blindgs. 

By the blindness of the BLINDSIGN scheme, the adversary is not able to distinguish blinded 
values from randomness. Thus, the adversary is unable to correlate a Signgs operation in refresh 
or withdraw with the unblinded value observed during Deposit. 

We conclude the success probability for G} must be 1/2 and hence the success probability for 


anon 


Exp} (1^, x, b) is at most 1/2 + e(A), where e is a negligible function. 


3.6.2 Conservation 


Theorem 2. Assuming existential unforgeability (EUF-CMA) of CoINSIGNKx, our instantiation satisfies 
conservation. 
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Proof. In honest executions, we have withdrawn[pkCustomer] = vc + Us, i.e., the coins withdrawn 
add up to the coins still available and the coins spent for known transactions. 

In order to win the conservation game, the adversary must increase withdrawn[pkCustomer] or 
decrease vc or vs. An adversary can abort withdraw operations, thus causing withdrawn[pkCustomer] 
to increase, while the customer does not obtain any coins. However, in step |4} the customer 
obtains coins from interrupted withdraw operations. Similarly, for the refresh protocol, aborted 
RefreshRequest / RefreshPickup operations that result in a coin's remaining value being reduced 
are completed in step [4] 

Thus, the only remaining option for the adversary is to decrease vc or vs with the ORefreshPickup 
and ODeposit oracles, respectively. 

Since the exchange verifies signatures made by the secret key of the coin that is being 
spent/refreshed, the adversary must forge this signature or have access to the coin's secret key. 
As we do not give the adversary access to the sharing oracle, it does not have direct access to any 
of the honest customer's coin secret keys. 

Thus, the adversary must either compute the coin's secret key from observing the coin's public 
key (e.g., during a partial deposit operation), or forge signatures directly. Both possibilities allow 
us to carry out a reduction against the unforgeability property of the CoINSIGNKx scheme, by 
injecting the challenger's public key into one of the coins. 


3.6.3 Unforgeability 
Theorem 3. Assuming the unforgeability of BLINDSIGN, our instantiation satisfies unforgeability. 


Proof. The adversary must have produced at least one coin that was not blindly signed by the 
exchange. In order to carry out a reduction from this adversary to a blind signature forgery, we 
inject the challenger’s public key into one randomly chosen denomination. Since we do not have 
access to the corresponding secret key of the challenger, signing operations for this denomination 
are replaced with calls to the challenger’s signing oracle in OWithdrawPickup and ORefreshPickup. 
For n denominations, an adversary against the unforgeability game would produce a blind 
signature forgery with probability 1/n. 


3.6.4 Income Transparency 

Theorem 4. Assuming 
* the unforgeability of BLINDSIGN, 
* the key exchange completeness of COINSIGNKx, 
* the pseudo-random function property of PRF, and 
* the collision resistance of H, 

our instantiation satisfies weak income transparency. 


Proof. We consider the directed forest on coins induced by the refresh protocol. It follows from 
unforgeability that any coin must originate from some customer’s withdraw in this graph. We 
may assume that all coin;,...,coin; originate from non-corrupted users, for some / < £. 

For any i < I, there is a final refresh operation R; in which a non-corrupted user could obtain 
the coin C’ consumed in the refresh via the linking protocol, but no non-corrupted user could 
obtain the coin provided by the refresh, as otherwise coin; gets marked as spent in step step [5 Set 
PR (R; | i< l}. 

During each R; € F, our adversary must have submitted a blinded coin and transfer public 
key for which the linking protocol fails to produce the resulting coin correctly, otherwise the coin 
would have been spent in step [3] In this case, we consider several non-exclusive cases 
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1. the execution of the refresh protocol is incomplete, 
2. the commitment for the y-th blinded coin and transfer public key is dishonest, 
3. a commitment for a blinded coin and transfer public key other than the y-th is dishonest, 


We show these to be exhaustive by assuming their converses all hold: As the commitment 
is signed by skCoing, our key exchange completeness assumption of CoINSIGNKx applies to 
the coin public key. Any revealed values must match our honestly computed commitments, 
as otherwise a collision in H would have been found. We assumed the revealed y-th transfer 
public key is honest. Hence our key exchange completeness assumption of COINSIGNKx yields 
Kexcsx(t,C’) = Kexcsx(c’, T) where T = KeyGenPubcsx(t) is the transfer key, thus the customer 
obtains the correct transfer secret. We assumed the refresh concluded and all submissions besides 
the y-th were honest, so the exchange correctly reveals the signed blinded coin. We assumed the 
y-th blinded coin is correct too, so customer now re-compute the new coin correctly, violating 
Rj € F. 

We shall prove 


p 1 
E [ssl o] K eo) 
where the expectation runs over any probability space used by the adversary and challenger. 

We shall now consider executions of the income transparency game with an optimal adversary 
with respect to maximizing Pu Note that this is permissible since we are not carring out a 
reduction, but are interested in the expectation of the game's return value. 

As a reminder, if a refresh operation is initiated using a false commitment that is detected by 
the exchange, then the new coin cannot be obtained, and contributes to the lost coins b :— w — s 
instead of the winnings p :— L — w'. We also note b 4- p gives the value of refreshes attempted 
with false commitments. As these are non-negative, jm is undefined if and only if p — 0 and 
b = 0, which happens if and only if the adversary does not use false commitments, i.e., F = Ø. 

We may now assume for optimality that .A submits a false commitment for at most one choice 
of y in any R; € F, as otherwise the refresh always fails. Furthermore, for an optimal adversary we 
can exclude refreshes in F that are incomplete, but that would be possible to complete successfully, 
as completing such a refresh would only increase the adversaries winnings. 

We emphasize that an adversary that loses an R; loses the coin that would have resulted from 
it completely, while an optimal adversary who wins an R; should not gamble again. Indeed, an 
adversary has no reason to touch its winnings from an R;. 

For any Rj, there are x game runs identical up through the commitment phase of R; and 
exhibiting different outcomes based on the challenger's random choice of y. If v; is the financial 
value of the coin resulting from refresh operation R; then one of the possible runs adds 7; to p, 
while the remaining x — 1 runs add v; to b. 

We define p; and bj to be these contributions summed over the x possible runs, i.e., 


Pi := Oj 
b; = (x = 1)vj 


The adversary will succeed in 1/x runs (p; — v) and loses in (x — 1)/x runs (p; — 0). Hence: 


E Lr o - m E E 


b+p IF| Ker bi + Pi 
1 v ,k-1 0 
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which yields the equality 63) 
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As for F = @, the return value of the game must be 0, we conclude 


; 1 
E [Epa < > 


3.7 Discussion 


3.71 Limitations 


Not all features of our implementation are part of the security model and proofs. In particular, 
the following features are left out of the formal discussion: 


* Reserves. In our formal model, we effectively assume that every customer has access to 
exactly one unlimited reserve. 


* Offline and online keys. In our implementation, the exchange has one offline master signing 
key, and online signing keys with a shorter live span. 


Refunds allow merchants to effectively “undo” a deposit operation before the exchange 
settles the transaction with the merchant. This simple extension preserves unlinkability of 
payments through refresh. 


Timeouts. In practice, a merchant gives the customer a deadline until which the payment 
for a contract must have been completed, potentially by using multiple coins. 


If a customer is unable to complete a payment (e.g., because they notice that their coins 
are already spent after a restore from backup), a refund for this partial payment can be 
requested from the merchant. 


Should the merchant become unavailable after a partially completed payment, there are 
two possibilities: Either the customer can deposit the coins on behalf of the merchant to 
obtain proof of their on-time payment, which can be used in a later arbitration if necessary. 
Alternatively, the customer can ask the exchange to undo the partial payments, though this 
requires the exchange to know (or learn from the customer) the exact amount to be paid for 
the contract. 


* The fees incurred for operations, the protocols for backup and synchronization as well as 
other possible extensions like tick payments are not formally modeled. 


We note that customer tipping (see[2.1.11) basically amounts to an execution of the Withdraw 
protocol where the party that generates the coin keys and blinding factors (in that case the 
merchant's customer) is different from the party that signs the withdraw request (the merchant 
with a “customer” key pair tied to the merchant's bank account). While this is desirable in 
some cases, we discussed in 2.1.1] how this “loophole” for a one-hop untaxed payment could be 
avoided. 


3.7.2 Other Properties 
Exculpability 


Exculpability is a property of offline e-cash which guarantees that honest users cannot be 
falsely blamed for misbehavior such as double spending. For online e-cash it is not necessary, 
since coins are spent online with the exchange. In practice, even offline e-cash systems that 
provide exculpability are often undesirable, since hardware failures can result in unintentional 
overspending by honest users. If a device crashes after an offline coin has been sent to the 
merchant but before the write operation has been permanently recorded on the user's device 
(e.g., because it was not yet flushed from the cache to a hard drive), the next payment will cause a 
double spend, resulting in anonymity loss and a penalty for the customer. 
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Fair Exchange 


The Endorsed E-Cash system by Camenisch et al. allows for fair exchange—sometimes 
called atomic swap in the context of cryptocurrencies—of online or offline e-cash against digital 
goods. The online version of Camenisch's protocol does not protect the customer against loss of 
anonymity from linkability of aborted fair exchanges. 

Taler's refresh protocol can be used for fair exchange of online e-cash against digital goods, 
without any loss of anonymity due to linkability of aborted transactions, with the following small 
extension: The customer asks the exchange to lock coins to a merchant until a timeout. Until the 
timeout occurs, the exchange provides the merchant with a guarantee that these coins can only 
be spent with this specific merchant, or not at all. The fair exchange exchanges the merchant's 
digital goods against the customer's deposit permissions for the locked coins. On aborted fair 
exchanges, the customer refreshes to obtain unlinkable coins. 
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Chapter 4 


Implementation of GNU Taler 


This chapter describes the implementation of GNU Taler in detail. Concrete design decisions, 
protocol details and our reference implementation are discussed. 

We implemented the GNU Taler protocol in the context of a payment system for the web, as 
shown in Figure[2.1] The system was designed for real-world usage with current web technologies 
and within existing financial systems. 

The following technical goals and constraints influenced the design of the concrete protocol 
and implementation: 


The implementation should allow payments in browsers with hardened security settings. 
In particular, it must be possible to make a payment without executing JavaScript on a 
merchant's website and without having to store (session-)cookies or requiring a login. 


Cryptographic evidence should be available to all parties in case of a dispute. 


In addition to the guarantees provided by the GNU Taler protocol, the implementation must 
take care to not introduce additional threats to security and privacy. Features that trade 
privacy for convenience should be clearly communicated to the user, and the user must 
have the choice to deactivate them. Integration with the web should minimize the potential 
for additional user tracking. 


The integration for merchants must be simple. In particular, merchants should not have to 
write code involving cryptographic operations or have to manage Taler-specific secrets in 
their own application processes. 


The web integration must not be specific to a single browser platform, but instead must be 
able to use the lowest common denominator of what is currently available. User experience 
enhancements supported for only specific platforms are possible, but fallbacks must be 
provided for other platforms. 


URLs should be clean, user-friendly and must have the expected semantics when sharing 
them with others or revisiting them after a session expired. 


Multiple currencies must be supported. Conversion between different currencies is out of 
scope. 


The implementation should offer flexibility with regards to what context or applications 
it can be used for. In particular, the implementation must make it possible to provide 
plugins for different underlying banking systems and provide hooks to deal with different 
regulatory requirements. 


The implementation must be robust against network failures and crash faults, and recover 
as gracefully as possible from data loss. Operations must be idempotent if possible, e.g., 
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accidentally clicking a payment button twice should only result in one payment, and 
refreshing a page should not lead to failures in the payment process. 


* Authorization should be preferred to authentication. In particular, there should be no 
situations in which the user must enter confidential information on a page that cannot be 
clearly identified as secure. 


* No flickering or unnecessary redirects. To complete a payment, the number of request, 
especially in the user’s navigation context, should be minimized. 


* While the implementation should integrate well with browsers, it must be possible to request 
and make payments without a browser. This makes at least part of the implementation 
completely independent of the extremely complex browser standards, and makes Taler 
usable for machine-to-machine payments. 


We now recapitulate how a GNU Taler payment works, with some more details specific to the 
implementation. 

By instructing their bank to send money to an exchange, the customer creates a (non- 
anonymous) balance, called a reserve, at the exchange. Once the exchange has received and 
processed the bank transfer, the customer’s wallet automatically drains the reserve by withdrawing 
coins from it until the reserve is empty. Withdrawing immediately before a purchase should 
be avoided, as it decreases the customer’s anonymity set by creating a correlation between the 
non-anonymous withdrawal and the spending. 

To withdraw coins from the exchange, the customer’s wallet authenticates itself using an 
Ed25519 private key for the customer’s reserve. The customer must include the corresponding 
reserve public key in the payment instruction from the customer’s bank to the exchange’s bank 
that funded their reserve. With a bank that directly supports Taler on their online banking website, 
this process is streamlined for the user, since the wallet automatically creates the key pair for the 
reserve and adds the public key to the payment instruction. 

While browsing a merchant's website, the website can signal the wallet to request a payment 
from a user. The user is then asked to confirm or reject this proposal. If the user accepts, 
the wallet spends coins with the merchant. The merchant deposits coins received from the 
customer's wallet at the exchange. Since bank transfers are usually costly, the exchange delays 
and aggregates multiple deposits into a bigger wire transfer. This allows GNU Taler to be used 
even for microtransactions of amounts smaller than usually handled by the underlying banking 
system. 

As shown in Figure the merchant is internally split into multiple components. The 
implementation of the Taler protocol and cryptographic operations is isolated into a separate 
component, called the merchant backend, which the merchant accesses through an API or software 
development kit (SDK) in the programming language of their choice. 

Our implementations of the exchange (70,000 LOC) and merchant backend (20,000 LOC) 
are written in C using PostgreSQL as the database and libgcrypt for cryptographic operations. 
The wallet (10,000 LOC) is implemented in TypeScript as a cross-browser extension using the 
WebExtensions API, which is available for a majority of widely used browsers. It also uses 
libgcrypt (compiled to JavaScript) for cryptographic operations as the required primitives are not 
yet natively supported by web browsers. Sample merchant websites (1,000 LOC) and an example 
bank (2,000 LOC) with tight Taler integration are provided in Python. 

The code is available at [https://git.taler.net/|and a demo is publicly available at 


4.1 Overview 


We provide a high-level overview over the implementation, before discussing the respective 
components in detail. 
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Figure 4.1: The different components of the Taler system in the context of a banking system 
providing money creation, wire transfers and authentication. (Auditor omitted.) 


4.1.1 Taler APIs 


The components of Taler communicate over an HTTP-based, RESTfu['|[FToo] API. All request 
payloads and responses are JSON documents. 

Binary data (such as key material, signatures and hashes) is encoded as a base32-crockford 
string. Base32-crockford is a simple, case-insensitive encoding of binary data into a subset 
of the ASCII alphabet that encodes 5 bits per character. While this is not the most space-efficient 
encoding, it is relatively resilient against human transcription errors. 

Financial amounts are treated as fixed-point decimal numbers. The implementation internally 
uses a pair of integers (v,f) with value part 0 < v < 2% and fractional part 0 < f < 108 
to represent the amount a = v + f-10~8. This representation was chosen as the smallest 
representable amount is equal to one Satoshi (the smallest representable amount in Bitcoin), and 
the largest possible value part (besides being large enough for typical financial applications) is 
still accurately representable in 64-bit IEEE 754 floating point numbers. These constraints are 
useful as some languages such as JavaScript?] provide IEEE 753 floating point numbers as the 
only numeric type. More importantly, fixed-point decimal numbers allow exact representation of 
decimal values (say € 0.10), which is not possible with floating point numbers but essential in 
financial applications. 

Signatures are made over custom binary representations of the respective values, prefixed 
with a 64-bit tag consisting of the size of the message (32 bits) and an integer tag (32 bits) 
uniquely identifying the purpose of the message. To sign a free-form JSON object, a canonical 
representation as a string is created by removing all white space and sorting objects” fields. 

In the future, more space-efficient representations (such as BSON?]or CBOR [BH13]) could be 
used. The representation can be negotiated between client and server in a backwards-compatible 
way with the HTTP “Accept” header. 


*Some REST purists might disagree, because the Taler APIs do not follow all REST principles religiously. In particular, 
the HATEOAS principle is not followed. 

*Big integers are currently in the process of being added to the JavaScript language standard. 

3http:/ /bsonspec.org / 
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Figure 4.2: Entities/PKI in Taler. Solid arrows denote signatures, dotted arrows denote blind 
signatures. 
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4.1.2 Cryptographic Algorithms 
The following cryptographic primitives are used by Taler: 
e SHA512 as a cryptographic hash function 
* Ed25519 for non-blind signing operations 
* Curve25519 for the refreshing operation 
HKDF as a key derivation function for the refreshing operation 
* FDH-RSA blind signatures 


We chose these primitives as they are simple, cheap enough and relatively well studied. Note 
that other signature schemes that have the syntax and properties described in Section [3.5.1] such 
as [Bolo3], could be used instead of FDH-RSA. 


4.1.3 Entities and Public Key Infrastructure 


The public key infrastructure (PKI) used by Taler is orthogonal to the PKI used by TLS [RDo8]. 
While TLS is used as the transport layer for Taler API messages, we do not rely on TLS for 
authenticity or integrity of API queries and responses. We do rely on TLS for the confidentiality 
of digital business contracts and the authenticity, integrity and confidentiality of digital product 
delivery. For the anonymity properties to hold, the customer must access the merchant and 
exchange through an anonymity layer (approximated by practical implementations like Tor 
(DVSo4p. 

In the case of merchants, we cannot use a trusted auditor or exchange as a trust anchor, since 
merchants are not required to register within our PKI to accept Taler payments. Here we rely on 
TLS instead: The merchant is required to include their Taler-specific merchant public key in their 
TLS certificate. If a merchant fails to do this, the wallet will show a warning when asking the user 
to confirm a payment. 
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{ 33 "stamp expire deposit": "/Date (1658130235) /", 
"version": "2:0:0", 34 "stamp expire legal": "/Date (1815810235) /", 
"master public key": "CQQZ...", 35 " | pu "SIRT", 

"reserve closing delay": "/Delay (2419200) /", 36 " "ٍ KUDOS:0.1" 
"signkeys": [ 37 ": "TESTKUDOS:0.01", 

( 38 "fee deposit "TESTKUDOS :0.01", 
"stamp start": "/Date(1522223035)/", 39 "fee refresh": "TESTKUDOS:0.01", 
"stamp expire": "/Date(1533109435)/", 40 "fee refund": "TESTKUDOS:0.01" 
"stamp end": "/Date(1585295035)/", 41 »h 
"master sig": "842D...", 42 A 
"key": "05XW..." 43 "auditors": [ 

} 44 { 

l 45 "denomination_keys": [ 
"payback": [], 46 { 
"denoms": [ 47 "denom pub h": 

{ 48 "auditor_sig": "6 
"master sig": " P 49 he 
"stamp start": "/Date (1500450235) /", 50 { 

"stamp expire withd "/Date (1595058235) /", 51 "denom pub h": "CP6B...", 

"stamp expire deposit": "/Date(1658130235)/", 52 "auditor sig": "OGSE..." 

"stamp expire legal": "/Date(1815810235)/", 53 ) 

"denom pub": "SIRD...", 54 p 

"value": "TESTKUDOS:10", 55 "auditor url": "https://auditor.test.taler.net/", 
"fee withdraw": "TESTKUDOS:0.01", 56 "auditor pub": "BW9DC..." 

"fee deposit": " 57 ) 

fee refres 58 m 

fee refund 59 "list, issue date": "/Date(1530196508)/", 

fy 60 "eddsa pub": "05XW...", 

{ 61 "eddsa sig": "RXCD..." 

"master sig": "QTOT...", 62 } 
"stamp start": "/Date (1500450235) /", 
"stamp expire withdraw": "/Date (1595058235) /", 


Figure 4.3: Example response for /keys 


Auditor 


Auditors serve as trust anchors for Taler, and are identified by a single Ed25519 public key. Wallet 
implementations come with a pre-defined list of trusted auditors, similar to the certificate store of 
browsers or operating systems. 


Exchange 


An exchange is identified by a long term Ed25519 master key and the exchange’s base URL. The 

master key is used as an offline signing key, typically stored on an air-gapped machine. API 

requests to the exchange are made by appending the name of the endpoint to the base URL. 
The exchange uses the master key to sign the following data offline: 


* The exchange’s online Ed25519 signing keys. The online signing keys are used to sign API 
responses from the exchange. Each signing key has a validity period. 


* The denominations offered by the exchange (explained further in Section 1.1.5). 


* The bank accounts supported by the exchange (for withdrawals and deposits) and associated 
fees. 


The «base-url»/keys HTTP endpoint of the exchange is used by wallets and merchants to 
obtain the exchange's signing keys, currently offered denominations and other details. In order to 
reduce traffic, clients can also request only signing keys and denominations that were created 
after a specific time. The response to /keys is signed by a currently active signing key, so that 
customers would have proof in case the exchange gave different sets of denomination keys to 
different customers in an attempt to deanonymize them. 


Coins and Denominations 


Denominations are the RSA public keys used to blindly sign coins of a fixed amount, together 
with information about their validity and associated fees. The following information is signed by 
the exchanges master key for every denomination: 


* The RSA public key. 


* The start date, after which coins of this denomination can be withdrawn and deposited. 
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Figure 4.4: A denomination’s lifetime. 


* The withdraw expiration date, after which coins cannot be withdrawn anymore, must be 
after the start date. 


* The deposit expiration date, after which coins cannot be deposited anymore, must be after 
the withdraw expiration date. 


The legal expiration date, after which the exchange can delete all records about operations 
with coins of this denominations, must be (typically quite a long time!) after the deposit 
expiration date. 


The fees for a withdraw, deposit, refresh and refund operation with this coin, respectively. 


An exchange can be audited by zero, one or multiple auditors. An auditor must monitor all 
denominations currently offered by the exchange, and an audit of a subset of denominations 
is not intended in the current design. To allow customers of an exchange to confirm that it 
is audited properly, the auditor signs an auditing request from the exchange, containing basic 
information about the exchange as well as all keys offered during the auditing period. In 
addition to the full auditing request, the auditor also signs an individual certificate for each 
denomination individually, allowing clients of the exchange to incrementally verify newly offered 
denominations. 


Merchant 


The merchant has one Ed25519 key pair that is used to sign responses to the customer and 
authenticate some requests to the exchange. Depending on the legislation that applies to a 
particular GNU Taler deployment, merchants might not need to establish an a priori relationship 
with the exchange, but instead send their bank account information during or after the first 
deposit of a payment from a customer. 

In some jurisdictions, exchanges are required to follow know-your-customer (KYC) regulations 
and to verify the identity of merchants using that particular exchange for deposits. 
Typically, the identity of a merchant only has to be verified if a merchant exceeds a certain 
threshold of transactions in a given time span. As the KYC registration process can be costly to 
the exchange, this requirement is somewhat at odds with merchants accepting payments from 
all exchanges audited by a trusted auditor, since KYC registration needs to be done at every 
exchange separately. It is, however, unavoidable to run a legally compliant payment system. 

A merchant is typically configured with a set of trusted auditors and exchanges, and conse- 
quently accepts payments with coins of denominations from a trusted exchange and denomina- 
tions audited by a trusted auditor. 

In order to make the deployment of Taler easier and more secure, the parts that deal with 
the merchant’s private key and cryptographic operations are isolated into a separate service (the 
merchant backend) with a well-defined RESTful HTTP API. This concept is similar to payment 
gateways used commonly for credit card payments. The merchant backend can be deployed 
on-premise by the online shop, or run by a third party provider that is fully trusted by the 
merchant. 
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Figure 4.5: The contract header that is signed by the merchant. 
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Figure 4.6: The deposit permission signed by the customer’s wallet. 


Bank 


Since the banks are third parties that are not directly part of Taler, they do not participate directly 
in Taler’s PKI. 


Customer 


Customers are not registered with an exchange, instead they use the private keys of reserves that 
they own to authenticate with the exchange. The exchange knows the reserve’s public key from 
the subject/instruction data of the wire transfer. Wire transfers that do not contain a valid public 
key are automatically reversed. 


4.1.4 Payments 


Payments in Taler are based on contract terms, a JSON object that describes the subject and 
modalities of a business transaction. The cryptographic hash of such a contract terms object can 
be used as a globally unique identifier for the business transaction. Merchants must sign the 
contract terms before sending them to the customer, allowing a customer to prove in case of a 
dispute the obligations of the merchant resulting from the payment. 

Unless a third party needs to get involved in a dispute, it is sufficient (and desirable for data 
minimization) that only the merchant and the customer know the full content of the contract terms. 
The exchange, however, must still know the parts of the contract terms that specify payment 
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modalities, such as the refund policy, micropayment aggregation deadline and the merchant's 
KYC registration data (typically a hash to prove the KYC enrollment of the merchant). 

Thus, the merchant’s signature is made over the contract header, which contains the contract 
terms hash, as well as the payment modalities. 

In addition to the data provided by the merchant, the contract terms contain a claim_pub field 
whose value is provided by the customer. This field is an Ed25519 public key, and the customer 
can use the corresponding private key to prove that they have indeed obtained the individual 
contract terms from the merchant, and did not copy contract terms that the merchant gave to 
another customer. Note that this key is not a permanent identity of the customer, but should be 
freshly generated for each payment. 

The signed contract header is created by the merchant’s backend from an order, which is 
the "blueprint" for the contract terms. The order is generated by the merchant's frontend and 
contains a subset of the data contained in the contract terms. Missing data (in particular the 
merchant's bank account information, public key and accepted auditors/exchanges) and the 
claim public key obtained from the customer is automatically added by the merchant backend. 
This allows applications to process payments without having to specify Taler-internal details. In 
fact, the smallest possible order only needs to contain two fields: the amount to be paid and a 
human-readable summary of the payment's subject. 

An order contains an order ID, which is an identifier that is unique within a given merchant 
and can be a human-friendly identifier such as a booking number. If the order ID is not manually 
provided, it is automatically filled in by the merchant backend. It can be used to refer to the 
payment associated with the order without knowing the contract terms hash, which is only 
available once the customer has provided their claim public key. 

To initiate a payment, the merchant sends the customer an unclaimed contract terms URL. The 
customer can download and thereby claim ownership of the contract by appending their claim 
public key p as a query parameter to the unclaimed contract terms URL and making an HTTP 
GET request to the resulting URL. The customer must then verify that the resulting contract terms 
are signed correctly by the merchant and that the contract terms contain their claim public key p. 
A malicious customer could try to claim other customers' contracts by guessing contract term 
URLs and appending their own claim public key. For products that have limited availability, the 
unclaimed contract URL must have enough entropy so that malicious customers are not able to 
guess them and claim them before the honest customer[!] 

To give an example, an online shop for concert tickets might allow users to put themselves on 
a waiting list, and will send them an email once a ticket becomes available. The contract terms 
URL that allows the customer to purchase the ticket (once they have visited a link in this email), 
should contain an unguessable nonce, as otherwise an attacker might be able to predict the URL 
and claim the contract for the concert ticket before the customer's wallet can. 

In order to settle the payment, the customer must sign a deposit permission for each coin that 
comprises the payment. The deposit permission is a message signed by the coin's private key, 
containing 


* the amount contributed by this coin to the payment, 

* the merchant's public key 

* the contract header together with the merchant's signature on it, 
* the time at which the deposit permission was signed. 


After constructing the deposit permissions for a contract, the customer sends them to the 
merchant by doing an HTTP POST request to the pay_url indicated by the merchant in the 
contract terms. The merchant individually deposits each deposit permission with the exchange. 


4Note that this URL cannot be protected by a session cookie, as it might be requested from a different session context 
than the user's browser, namely in the wallet. 
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The merchant responds with a payment confirmation to the customer after it has successfully 
deposited the customer’s coins with the exchange. The payment confirmation can be used by the 
customer to prove that they completed the payment before the payment deadline indicated in the 
contract terms. 

Note that the depositing multiple coins with the exchange deliberately does not have trans- 
actional semantics. Instead, each coin is deposited in an individual transaction. This allows the 
exchange to be horizontally scaled (as discussed in Section [4.9) more easily, as deposit transaction 
might otherwise have to span multiple database shards. 

The lack of transactional semantics, however, means that it must be possible to recover from 
partially completed payments. There are several cases: If one of the coins that the customer 
submitted as payment to the merchant is invalid (e.g., because the wallet’s state was restored 
from a backup), the customer can re-try the partially completed payment and provide a different 
coin instead. If that is not possible or desired by the customer, the merchant may voluntarily give 
a refund on the coins that have been previously deposited. The reference implementation of the 
merchant backend offers refunds for partially completed payments automatically. 

If refunds were disabled for the payment, the merchant does not cooperate in giving refunds for 
a partially completed payment, or becomes unresponsive after partially depositing the customer’s 
coin, the customer has two options: They can either complete the deposits on the merchant's 
behalf, and then use the deposit permissions to prove (either to the merchant or to a court) that 
they completed the payment. 

Another possibility would be to allow customers to request refunds for partially completed 
payments themselves, directly from the exchange. This requires that the merchant additionally 
includes the amount to be paid for the contract in the contract header, as the exchange needs to 
know that amount to decide if a payment with multiple coins is complete. We do not implement 
this approach, since it implies that the exchange always learns the exact prices of products that 
the merchant sells, as opposed to just the merchant’s total revenue. 

The customer could also reveal the contract terms to the exchange to prove that a payment is 
incomplete, but this is undesirable for privacy reasons, as the exchange should not learn about 
the full details of the business agreement between customer and merchant. 


4.1.5 Resource-based Web Payments 


In order to integrate natively with the concepts and architecture of the web, Taler supports paying 
for a web resource in the form of a URL. In fact all Taler contract terms contain a fulfillment URL, 
which identifies the resource that is being paid for. If the customer is not paying for a digital 
product (such as an movie, song or article), the fulfillment URL can point to a confirmation page 
that shows further information, such as a receipt for a donation or shipment tracking information 
for a physical purchase. A fulfillment URL does not necessarily refer to a single item, but could 
also represent a collection such as a shopping basket. 
The following steps illustrate a typical payment with the online shop alice-shop.exampl 

com. 


1. The user opens the shop’s page and navigates to a paid resource, such as https: // 
alice-shop.example.com/essay-24.pdf. 


2. The shop sends a response with HTTP status "402 Payment Required" with the headers 
(— marks a continued line) 


Taler-Contract-Url:,https://alice-shop.example.com/ 

— contract?product-essay-24.pdf 

Taler-Resource-Url:,https://alice-shop.example.com/ 
> essay-24.pdf 


3. Since the user's wallet does not yet contain contract terms with the fulfillment URL nttps: 
//alice-shop.example.com/esasy-24.pdf that matches the resources URL, it claims 
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the contract by generating a claim key pair (s, p) and requesting the contract URL with 
the claim public key p as additional parameter: https: //alice-shop.example.com/ 
contract ?product=essay-24.pdf&claim_pub=p. 


4. The wallet displays the contract terms to the customer and asks them to accept or decline. If 
the customer accepted the contract, the wallet sends a payment to the merchant. After the 
merchant received a valid payment, it marks the corresponding order as paid. 


5. The wallet constructs the extended fulfillment URL by adding the order id from the 
contract as an additional parameter and navigates the browser to the resulting URL https: 
//alice-shop.example.com/esasy-24.pdf?order id-.... 


6. The shop receives the request to the extended fulfillment URL and checks if the payment 
corresponding to the order ID was completed. In case the payment was successful, it serves 
the purchased content. 


To avoid checking the status of the payment every time, the merchant can instead set a 
session cookie (signed /encrypted by the merchant) in the user's browser which indicates that 
essay-24.paf has been purchased. 

The resource-based payment mechanism must also handle the situation where a customer 
navigates again to a resource that they already paid for, without directly navigating to the 
extended fulfillment URL. In case no session cookie was set for the purchase or the cookie was 
deleted / has expired, the customer would be prompted for a payment again. To avoid this, 
the wallet tries to find an existing contract whose plain fulfillment URL matches the resource 
URL specified in the merchant's HTTP 402 response. If such an existing payment was found, 
the wallet instead redirects the user to the extended fulfillment URL for this contract, instead of 
downloading the new contract terms and prompting for payment. 

In the example given above, the URL that triggers the payment is the same as the fulfillment 
URL. This may not always the case in practice. When the merchant backend is hosted by a 
third party, say https: //bob.example.com/, the page that triggers the payment even has a 
different origin, i.e., the scheme, host or port may differ [Bar11]. 

This cross-origin operation presents a potential privacy risk if not implemented carefully. 
To check whether a user has already paid for a particular resource with URL u, an arbitrary 
website could send an HTTP 402 response with the “Taler-Resource-Url” header set to u and 
the “Taler-Contract-Url” set to a URL pointing to the attacker's server. If the user paid for u, the 
wallet will navigate to the extended fulfillment URL corresponding to u. Otherwise, the wallet 
will try to download a contract from the URL given by the attacker. In order to prevent this attack 
on privacy, the wallet must only redirect to u if the origin of the page responding with HTTP 402 
is the same origin as either the u or the pay URLP| 


Loose Browser Integration 


The payment process we just described does not directly work in browsers that do not have native 
Taler integration, as the browser (or at least a browser extension) would have to handle the HTTP 
status code 402 and handle the Taler-specific headers correctly. We now define a fallback, which 
is transparently implemented in the reference merchant backend. 

In addition to indicating that a payment is required for a resource in the HTTP status code and 
header, the merchant includes a fallback URL in the body of the “402 Payment Required” response. 
This URL must have the custom URL scheme taler, and contains the contract terms URL (and 
other Taler-specific settings normally specified in headers) as parameters. The above payment 
would include a link (labeled, e.g., “Pay with GNU Taler”) to the following URL, encoding the 
same information as the headers: 


5This type of countermeasure is well known in browsers as the same origin policy, as also outlined in [Barıı]. 


4.1. OVERVIEW 69 


taler:pay? 
— contract_url= 


— https$3A$2F$2Falice-shop.example.com$2Fcontract£3Fproduct$3 
“> Dessay-24.pdf 
=} &resource url- 
“> https$3A$2F$2Falice-shop.example.com$2Fessay-24.pdf 


This fallback can be disabled for requests from user agents that are known to natively support 
GNU Taler. 

GNU Taler wallet applications register themselves as a handler for the taler URI scheme, and 
thus following a taler:pay link opens the dedicated wallet, even if GNU Taler is not supported 
by the browser or a browser extension. Registration a custom protocol handler for a URI scheme 
is possible on all modern platforms with web browsers that we are aware of. 

Note that wallets communicating with the merchant do so from a different browsing context, 
and thus the merchant backend cannot rely on cookies that were set in the customer's browser 
when using the shop page. 

We chose HTTP headers as the primary means of signaling to the wallet (instead of relying on, 
e.g., a new content media type), as it allows the fallback content to be an HTML page that can be 
rendered by all browsers. Furthermore, current browser extension mechanism allow intercepting 
headers synchronously before the rendering of the page is started, avoiding visible flickering 
caused by intermediate page loads. 


4.1.6 Session-bound Payments and Sharing 


As we described the payment protocol so far, an extended fulfillment URL is not bound to a 
browser session. When sharing an extended fulfillment URL, another user would get access to the 
same content. This might be appropriate for some types of fulfillment pages (such as a donation 
receipt), but is generally not appropriate when digital content is sold. Even though it is trivial to 
share digital content unless digital restrictions management (DRM) is employed, the ability to 
share links might set the bar for sharing too low. 

While the validity of a fulfillment URL could be limited to a certain time, browser session or IP 
address, this would be too restrictive for scenarios where the user wants to purchase permanent 
access to the content. 

As a compromise, Taler provides session-bound payments. For session-bound payments, the 
seller’s website assigns the user a random session ID, for example, via a session cookie. The 
extended fulfillment URL for session-bound payments is constructed by additionally specifying 
the URL parameter session_sig, which contains proof that the user completed (or re-played) 
the payment under their current session ID. 

To initiate a session-bound payment, the HTTP 402 response must additionally contain the 
“Taler-Session-Id” header, which will cause the wallet to additionally obtain a signature on the 
session ID from the merchant’s pay URL, by additionally sending the session ID when executing 
(or re-playing) the payment. As an optimization, instead of re-playing the full payment, the wallet 
can also send the session ID together with the payment receipt it obtained from the completed 
payment with different session ID. 

Before serving paid content to the user, the merchant simply checks if the session signature 
matches the assigned session and contract terms. To simplify the implementation of the frontend, 
this signature check can be implemented as a request to the GNU Taler backend. Using session 
signatures instead of storing all completed session-bound payments in the merchant’s database 
saves storage. 

While the coins used for the payment or the payment receipt could be shared with other 
wallets, it is a higher barrier than just sharing a URL. Furthermore, the merchant could restrict 
the rate at which new sessions can be created for the same contract terms and restrict a session to 
one IP address, limiting sharing. 
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For the situation where a user accesses a session-bound paid resource and neither has a 
corresponding contract in their wallet nor does the merchant provide a contract URL to buy 
access to the resource, the merchant can specify an offer URL in the “Taler-Offer-Url” header. If 
the wallet is not able to take any other steps to complete the payment, it will redirect the user to 
the offer URL. As the name suggests, the offer URL can point to a page with alternative offers for 
the resource, or some other explanation as to why the resource is not available anymore. 


4.1.7 Embedded Content 


So far we only considered paying for a single, top-level resource, namely the fulfillment URL. In 
practice, however, websites are composed of many subresources such as embedded images and 
videos. 

We describe two techniques to “paywall” subresources behind a GNU Taler payment. Many 
other approaches and variations are possible. 


1. Visiting the fulfillment URL can set a session cookie. When a subresource is requested, the 
server will check that the customer has the correct session cookie set. 


2. When serving the fulfillment page, the merchant can add an additional authentication 
token to the URLs of subresources. When the subresource is requested, the validity of 
the authentication token is checked. If the merchant itself (instead of a Content Delivery 
Network that supports token authentication) is serving the paid subresource, the order ID 
and session signature can also be used as the authentication token. 


It would technically be possible to allow contract terms to refer to multiple resources that are 
being purchased by including a list or pattern that defines a set of URLs. The browser would 
then automatically include information to identify the completed payment in the request for 
the subresource. We deliberately do not implement this approach, as it would require deeper 
integration in the browser than possible on many platforms. If not restricted carefully, this feature 
could also be used as an additional method to track the user across the merchant's website. 


4.1.8 Contract Terms 


The contract terms, only seen by the customer and the merchant (except when a tax audit of the 
merchant is requested) contain the following information: 


* The total amount to be paid, 


e the pay. url, an HTTP endpoint that receives the payment, 


the deadline until the merchant accepts the payment (repeated in the signed contract 
header), 


the deadline for refunds (repeated in the signed contract header), 


the claim public key provided by the customer, used to prove they have claimed the contract 
terms, 


the order ID, which is a short, human-friendly identifier for the contract terms within the 
merchant, 


* the fulfillment url, which identifies the resources that is being paid for, 
* ahuman-readable summary and product list, 


* the fees covered by the merchant (if the fees for the payment exceed this value, the customer 
must explicitly pay the additional fees), 
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* depending on the underlying payment system, KYC registration information or other 
payment-related data that needs to be passed on to the exchange (repeated in the signed 
contract header), 


* the list of exchanges and auditors that the merchants accepts for the payment, 


* information about the merchant, including the merchant public key and contact information. 


4.1.9 Refunds 


By signing a refund permission, the merchant can “undo” a deposit on a coin, either fully or 
partially. The customer can then spend (or refresh) the refunded value of the coin again. A refund 
is only possible before the refund deadline (specified in the contract header). After the refund 
deadline has passed (and before the deposit deadline) the exchange makes a bank transfer the 
merchant with the aggregated value from deposits, a refund after this point would require a bank 
transfer back from the merchant to the exchange. 

Each individual refund on each coin incurs fees; the refund fee is subtracted from the amount 
given back to the customer and kept by the exchange. 

Typically a refund serves either one of the following purposes: 


e An automatic refund is given to the customer when a payment only partially succeeded. This 
can happen when a customer’s wallet accidentally double-spends, which is possible even 
with non-malicious customers and caused by data loss or delayed /failed synchronization 
between the same user's wallet on multiple devices. In these cases, the user can choose to 
re-try the payment with different, unspent coins (if available) or to ask for a refund from 
the merchant. 


A voluntary refund can be given at the discretion of the merchant, for example, when the 
customer is not happy with their purchase. 


Refunds require a signature by the merchant, but no consent from the customer. 

A customer is notified of a refund with the HTTP 402 Payment Required status code and the 
“Taler-Refund” header. The value of the refund header is a URL. An HTTP GET request on that 
URL will return a list of refund confirmations that the merchant received from the exchange. 


4.1.10 Tipping 


Tipping in Taler uses the ^withdraw loophole" (see 2.1.11) to allow the merchan] to donate small 
amounts (without any associated contract terms or legal obligations) into the user’s wallet. 

To be able to give tips, the merchant must create a reserve with an exchange. The reserve 
private key is used to sign blinded coins generated by the user that is being given the tip. 

The merchant triggers the wallet by returning an HTTP 402 Payment Required response that 
includes the “Taler-Tip” header. The value of the tip header (called the tip token) contains 


* the amount of the tip, 

* the exchange to use, 

* a URL to redirect after processing the tip, 

e a deadline for picking up the tip, 

* a merchant-internal unique ID for the tip, and 


* the pickup URL for the tip. 


6We still use the term “merchant”, since donations use the same software component as the merchant, but "donor" 
would be more accurate. 
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Upon receiving the tip token, the wallet creates coin planchets that sum up to at most the amount 
specified in the tip token, with denominations offered by the exchange specified in the tip token. 

The list of planchets is then sent to the merchant via an HTTP POST request to the tip-pickup 
URL. The merchant creates a withdrawal confirmation signature for each planchet, using the 
private key of the tipping reserve, and responds to the HTTP POST request with the resulting list 
of signatures. The user then uses these signatures in the normal withdrawal protocol with the 
exchange to obtain coins “paid for” by the merchant, but anonymized and only spendable by the 
customer. 


4.2. Bank Integration 


In order to use Taler for real-world payments, it must be integrated with the existing banking 
system. Banks can choose to tightly integrate with Taler and offer the ability to withdraw coins 
on their website. Even existing banks can be used to withdraw coins via a manual bank transfer 
to the exchange, with the only requirement that the 52 character alphanumeric, case-insensitive 
encoding of the reserve public key can be included in the transaction without modification other 
than case folding and white space normalization[] 


4.2.1 Wire Method Identifiers 


We introduce a new URI scheme payto, which is used in Taler to identify target accounts across 
a wide variety of payment systems with uniform syntax. 
In in its simplest form, a payto URI identifies one account of a particular payment system: 


'payto://' TYPE '/' ACCOUNT 


When opening a payto URI, the default action is to open an application that can handle 
payments with the given type of payment system, with the target account pre-filled. In its 
extended form, a payto URL can also specify additional information for a payment in the query 
parameters of the URI. 

In the generic syntax for URIs, the payment system type corresponds to the authority, the 
account corresponds to the path, and additional parameters for the payment correspond to the 
query parameters. Conforming to the generic URI syntax makes parsing of payto URIs trivial 
with existing parsers. 

Formally, a payto URI is an encoding of a partially filled out pro forma invoice. The full 
specification of the payto URI is RFC XXXX. 

In the implementation of Taler, payto URIs are used in various places: 


1. The exchange lists the different ways it can accept money as payto URIs. If the exchange 
uses payment methods that do not have tight Taler integration. 


2. In order to withdraw money from an exchange that uses a bank account type that does 
not typically have tight Taler integration, the wallet can generate a link and a QR code that 
already contains the reserve public key. When scanning the OR code with a mobile device 
that has an appropriate banking app installed, a bank transfer form can be pre-filled and 
the user only has to confirm the transfer to the exchange. 


3. The merchant specifies the account it wishes to be paid on as a payto URI, both in the 
configuration of the merchant backend as well as in communication with the exchange. 


A major advantage of encoding payment targets as URIs is that URI schemes can be registered 
with an application on most platforms, and will be "clickable" in most applications and open the 


7Some banking systems specify that the subject of the can be changed, and provide an additional machine-readable 
"instruction" field. 
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right application when scanned as a QR code. This is especially useful for the first use case listed 
above; the other use cases could be covered by defining a media type instead [FKH15]. 

As an example, the following OR code would open a banking application that supports SEPA 
payments, pre-filled with a 15€ donation to the bank account of GNUnet: 


4.2.2 Demo Bank 


For demonstration purposes and integration testing, we use our toy bank implementatior[”] which 
might be used in the future for regional currencies or accounting systems (e.g., for a company 
cafeteria). The payment type identifier is taler—bank. The authority part encodes the base URL 
of the bank, and the path must be the decimal representation of a single integer between 1 and 
252, denoting the internal demo bank account number. 


4-2.3 EBICS and SEPA 


The Electronic Banking Internet Communication Standard?|(EBICS) is a standard for communi- 
cating with banks, and is widely used in Germany, France and Switzerland, which are part of 
the Single European Payment Area (SEPA). EBICS itself is just a container format. A commonly 
supported payload for EBICS is ISO 2022, which defines messages for banking-related business 
processes. 

Integration of GNU Taler with EBICS is currently under development, and would allow Taler 
to be easily deployed in many European countries, provided that the exchange provider can 
obtain the required banking license. 


4.2.4 Blockchain Integration 


Blockchains such as Bitcoin could also be used as the underlying financial system for GNU Taler, 
provided that merchants and customers trust the exchange to be honest. 

With blockchains that allow more complex smart contracts, the auditing functionality could be 
implemented by the blockchain itself. In particular, the exchange can be incentivized to operate 
correctly by requiring an initial safety deposit to the auditing smart contract, which is distributed 
to defrauded participants if misbehavior of the exchange is detected. 


4.3 Exchange 
The exchange consists of three independent processes: 


* The taler-exchange-httpd process handles HTTP requests from clients, mainly mer- 
chants and wallets. 


* The taler-exchange-wirewatch process watches for wire transfers to the exchange’s 
bank account and updates reserves based on that. 


* The taler-exchange-aggregator process aggregates outgoing transactions to mer- 
chants. 


"https://git.taler.net/bank.git 


Shttp://www.ebics.org 
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Figure 4.7: Architecture of the exchange reference implementation 


All three processes exchange data via the same database. Only taler-exchange-httpd needs 
access to the exchanges online signing keys and denomination keys. 

The database is accessed via a Taler-specific database abstraction layer. Different databases 
can be supported via plugins; at the time of writing this, only a PostgreSQL plugin has been 
implemented. 

Wire plugins are used as an abstraction to access the account layer that Taler runs on. Specifi- 
cally, the wirewatch process uses the plugin to monitor incoming transfers, and the aggregator 
process uses the wire plugin to make wire transfers to merchants. 

The following APIs are offered by the exchange: 


Announcing keys, bank accounts and other public information The exchange offers the list of 
denomination keys, signing keys, auditors, supported bank accounts, revoked keys and 
other general information needed to use the exchange’s services via the /keys and /wire 
APIs. 


Obtaining entropy As we cannot be sure that all client-devices have an adequate random number 
generator, the exchange offers the /seed endpoint to download some high-entropy value. 
Clients should mix this seed with their own, locally-generated entropy into an entropy pool. 


Reserve status and withdrawal After having wired money to the exchange, the status of the 
reserve can be checked via the /reserve/$RESERVE PUB/status API. Since the wire 
transfer usually takes some time to arrive at the exchange, wallets should periodically poll 
this API, and initiate a withdrawal with /reserve/SRESERVE_PUB/withdraw once the 
exchange received the funds. 


Deposits and tracking Merchants transmit deposit permissions they have received from cus- 
tomers to the exchange via the /coins/$COIN_PUB/deposit API. Since multiple deposits 
are aggregated into one wire transfer, the merchant additionally can use the exchange’s 
/transfers/$WTID API that returns the list of deposits for a wire transfer identifier 


(WTID) included in the wire transfer to the merchant, as well as the /deposits/S$H WIRE 


,/ SME 


API to look up which wire transfer included the payment for a given deposit. 


'«RCHANT PUB/$H | 
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Figure 4.8: Data flow for updating the exchange’s keys. 


Refresh Refreshing consists of two stages. First, using /coins/$COIN PUB/melt an old, 
possibly dirty coin is melted and thus devaluted. The commitment made by the wallet 
during the melt and the resulting y-challenge from the exchange are associated with a 
refresh session. Then, using /refreshes/$RCH/reveal the wallet can answer the challenge 
and obtain fresh coins as change. Finally, /coins/$COIN PUB/link provides the link 
deterrent against refresh abuse. 


Refunds The refund API (/coins/$COIN_PUB/refund) can “undo” a deposit if the merchant 
gave their signature, and the aggregation deadline for the payment has not occurred yet. 


Recoup The recoup API (/coins/$COIN PUB/recoup) allows customers to be compensated 
for coins whose denomination key has been revoked. Customers must send either a full 
withdrawal transcript that includes their private blinding factor, or a refresh transcript (of a 
refresh that had the revoked denominations as one of the targets) that includes blinding 
factors. In the former case, the reserve is credited, in the latter case, the source coin of the 
refresh is refunded and can be refreshed again. 


New denomination and signing keys are generated and signed with the exchange's master 
secret key using the taler-exchange-keyup utility, according to a key schedule defined in the 
exchange's configuration. This process should be done on an air-gapped offline machine that has 
access to the exchange's master signing key. 

Generating new keys with taler-exchange-keyup also generates an auditing request file, 
which the exchange should send its auditors. The auditors then certify these keys with the 
taler-auditor-sign tool. 

This process is illustrated in Figure [4.8] 


4.4 Auditor 


The auditor consists of several main components: 


* the taler-auditor-dbinit tool to setup, upgrade or garbage-collect an auditor's 
database, 
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* the taler-auditor-exchange tool to add an exchange to the list of audited exchanges, 


* the taler-auditor-sign tool to sign an exchange's keys to affirm that the auditor is 
auditing this exchange, 


e an HTTP service (taler-auditor-httpd) which receives deposit confirmations from 
merchants, and 


e the taler-auditor script which must be regularly run to generate audit reports. 


4.4.1 Database synchronization 


FIXME: describe issue of how to synchronize exchange and auditor databases, and how we solved 
it (once we did solve it!) here. 


4.4.2 Thetaler-auditor tool 


The taler-auditor script uses several helper processes. These helper processes access the 
exchange's database, either directly (for exchange-internal auditing as part if its operational 
security) or over a replica (in the case of external auditors). 

The taler-auditor script ultimately generates a report with the following information: 


* Do the operations stored in a reserve's history match the reserve's balance? 


* Did the exchange record outgoing transactions to the right merchant for deposits after the 
deadline for the payment was reached? 


* Do operations recorded on coins (deposit, refresh, refund) match the remaining value on 
the coin? 


* Do operations respect the expiration of denominations? 


* For a denomination, is the number of pairwise different coin public keys recorded in 
deposit/refresh operations smaller or equal to the number of blind signatures recorded in 
withdraw /refresh operations? If this invariant is violated, the corresponding denomination 
must be revoked. 


* What is the income if the exchange from different fees? 


Report generation 


The taler-auditor script invokes its helper processes, each of which generates a JSON file 
with the key findings. The master script then uses Jinja2 templating to fill a LaTeX template with 
the key findings, and runs pdflatex to generate the final PDF. 

It is also possible to run the helper processes manually, and given that only one of them 
requires read-only access to the bank account of the exchange, this may be useful to improve 
parallelism or enhance privilege separation. Thus, taler-auditor is really only a convenience 
script. 


Incremental processing 


The operation of all auditor helper processes is incremental. There is a separate database to 
checkpoint the auditing progress and to store intermediate results for the incremental computation. 
Most database tables used by the exchange are append-only: rows are only added but never 
removed or changed. Tables that are destructively modified by the exchange only store cached 
computations based on the append-only tables. Each append-only table has a monotonically 
increasing row ID. Thus, the auditor's checkpoint simply consists of the set of row IDs that were 
last seen. 
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The taler-helper-auditor-aggregation 


This tool checks that the exchange properly aggregates individual deposits into wire transfers 


(see Figure|2.3). 


The list of invariants checked by this tool thus includes: 


* That the fees charged by the exchange are those the exchange provided to the auditor earlier, 
and that the fee calculations (deposit fee, refund fee, wire fee) are correct. Refunds are 
relevant because refunded amounts are not included in the aggregate balance. 


* The sanity of fees, as fees may not exceed the contribution of a coin (so the deposit fee 
cannot be larger than the deposited value, and the wire fee cannot exceed the wired amount). 
Similarly, a coin cannot receive refunds that exceed the deposited value of the coin, and the 
deposit value must not exceed the coin’s denomination value. 


e That the start and end dates for the wire fee structure are sane, that is cover the timeframe 
without overlap or gaps. 


* That denomination signatures on the coins are valid and match denomination keys known 
to the auditor. 


* That the target account of the outgoing aggregate wire transfer is well-formed and matches 
the account specified in the deposit. 


* That coins that have been claimed in an aggregation have a supporting history. 


* That coins which should be aggregated are listed in an aggregation list, and that the 
timestamps match the expected dates. 


The taler-helper-auditor-coins 


This helper focuses on checking the history of individual coins (as described in Figure 2-4), 
ensuring that the coin is not double-spent (or over-spent) and that refreshes, refunds and recoups 
are processed properly. 

Additionally, this tool includes checks for denomination key abuse by verifying that the value 
and number of coins deposited in any denomination does not exceed the value and number of 
coins issued in that denomination. 

Finally, the auditor will also complain if the exchange processes denominations that it did not 
properly report (with fee structure) to the auditor. 

The list of invariants checked by this tool thus includes: 


* Testing for an emergency on denominations because the value or number of coins deposited 
exceeds the value or number of coins issued; if this happens, the exchange should revoke 
the respective denomination. 


* Checking for arithmetic inconsistencies from exchanges not properly calculating balances or 
fees during the various coin operations (withdraw, deposit, melt, refund); 


* That signatures are correct for denomination key revocation, coin denominations, and coin 
operations (deposit, melt, refund, recoup) 


* That denomination keys are known to the auditor. 
* That denomination keys were actually revoked if a recoup is granted. 


* Whether there exists refresh sessions from coins that have been melted but not (yet) revealed 
(this can be harmless and no fault of the exchange, but could also be indicative of an 
exchange failing to process certain requests in a timely fashion). 


* That the refund deadline is not after the wire deadline (while harmless, such a deposit 
makes inconsistent requirements and should have been rejected by the exchange). 
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The taler-helper-auditor-deposits 


This tool verifies that the deposit confirmations reported by merchants directly to the auditor 
are also included in the database we got from the exchange. This is to ensure that the exchange 
cannot defraud merchants by simply not reporting deposits to the auditor or an exchange signing 
key being compromised (as described in Section ). 


The taler-helper-auditor-reserves 


This figure checks the exchange’s processing of the balance of an individual reserve, as described 


in Figure 


The list of invariants checked by this tool thus includes: 
* Correctness of the signatures that legitimized withdraw and recoup operations. 


* Correct calculation of the reserve balance given the history of operations (incoming wire 
transfers, withdraws, recoups and closing operations) involving the reserve. 


* That the exchange closed reserves when required, and that the exchange wired the funds 
back to the correct (originating) wire account. 


* Knowledge of the auditor of the denomination keys involved in withdraw operations and 
of the applicable closing fee. 


* That denomination keys were valid for use in a withdraw operation at the reported time of 
withdrawal. 


* That denomination keys were eligible for recoup at the time of a recoup. 


The taler-helper-auditor-wire 


This helper process checks that the incoming and outgoing transfers recorded in the exchange's 
database match wire transfers of the underlying bank account. To access the transaction history 
(typically recorded by the bank), the wire auditor helper is special in that it must be provided the 
necessary credentials to access the exchange's bank account. In a production setting, this will 
typically require the configuration and operation of a Nexus instance (of LibEuFin) at the auditor. 

The actual logic of the wire auditor is pretty boring: it goes over all bank transactions that 
are in the exchange's database, and verifies that they are present in the records from the bank, 
and then it goes over all bank transactions reported by the bank, and again checks that they are 
also in the exchange's database. This applies for both incoming and outgoing wire transfers. The 
tool reports any inconsistencies, be they in terms of wire transfer subject, bank accounts involved, 
amount that was transferred, or timestamp. 

For incoming wire transfers, this check protects against the following failures: An exchange 
reporting the wrong amount may wrongfully allow or refuse the withdrawal of coins from a 
reserve. The wrong wire transfer subject might allow the wrong wallet to withdraw, and reject 
the rightful owner. The wrong bank account could result in the wrong recipient receiving funds 
if the reserve is closed. Timestamp differences are usually pretty harmless, and small differences 
may even occur due to rounding or clock synchronization issues. However, they are still reported 
as they may be indicative of other problems. 

For outgoing wire transfers, the implications arising from an exchange making the wrong 
wire transfers should be obvious. 

The list of invariants checked by this tool thus includes: 


* The exchange correctly listing all incoming wire transfers. 


* The bank/Nexus having correctly suppressed incoming wire transfers with non-unique 
wire transfer subjects, and having assigned each wire transfer a unique row ID/offset. 
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Figure 4.9: Architecture of the merchant reference implementation 


* The exchange correctly listing all outgoing wire transfers including having the appropriate 
justifications (aggregation or reserve closure) for the respective amounts and target accounts. 


* Wire transfers that the exchange has failed to execute that were due. Note that small delays 
here can be normal as wire transfers may be in flight. 


4.4.3 The Auditor’s HTTP service 


The auditor exposes a web server with the taler-auditor-httpd process. Currently, it shows 
a website that allows the customer to add the auditor to the list of trusted auditors in their wallet. 
It also exposes an endpoint for merchants to submit deposit confirmations. These merchant- 
submitted deposit confirmations are checked against the deposit permissions in the exchange's 
database to detect compromised signing keys or missing writes, as described in Section ??. 

In the future, we plan for the auditor to expose additional endpoints where wallets and 
merchant backends can submit (cryptographic) proofs of missbehavior from an exchange. The goal 
would be to automatically verify the proofs, take corrective action by including the information in 
the audit report and possibly even compensating the victim. 


4.5 Merchant Backend 


The Taler merchant backend is a component that abstracts away the details of processing Taler 
payments and provides a simple HTTP API. The merchant backend handles cryptographic 
operations (signature verification, signing), secret management and communication with the 
exchange. 

The backend APY lis divided into two types of HTTP endpoints: 


1. Functionality that is accessed internally by the merchant. These APIs typically require 
authentication and/or are only accessible from within the private network of the merchant. 


2. Functionality that is exposed publicly on the Internet and accessed by the customer’s wallet 
and browser. 


10See https://docs.taler.net/api/ for the full documentation 
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A typical merchant has a storefront component that customers visit with their browser, as 
well as a back office component that allows the merchant to view information about payments 
that customers made and that integrates with other components such as order processing and 


shipping. 


4.5.1 Processing payments 


To process a payment, the storefront first instructs the backend to create an order. The order 
contains information relevant to the purchase, and is in fact a subset of the information contained 
in the contract terms. The backend automatically adds missing information to the order details 
provided by the storefront. The full contract terms can only be signed once the customer provides 
the claim public key for the contract. 

Each order is uniquely identified by an order ID, which can be chosen by the storefront or 
automatically generated by the backend. 

The order ID can be used to query the status of the payment. If the customer did not pay for an 
order ID yet, the response from the backend includes a payment redirect URL. The storefront can 
redirect the customer to this payment redirect URL; visiting the URL will trigger the customer's 
browser / wallet to prompt for a payment. 

To simplify the implementation of the storefront, the merchant backend can serve a page 
to the customer's browser that triggers the payment via the HTTP 402 status code and the 
corresponding headers, and provides a fallback (in the form of a taler:pay link) for loosely 
integrated browsers. When checking the status of a payment that is not settled yet, the response 
from the merchant backend will contains a payment redirect URL. The storefront redirects the 
browser to this URL, which is served by the merchant backend and triggers the payment. 

The code snippet shown in Figure implements the core functionality of a merchant 
frontend that prompts the customer for a donation (upon visiting /donate with the right query 
parameters) and shows a donation receipt on the fulfillment page with URL /receipt. The 
code snippet is written in Python and uses the Flask library] to process HTTP requests. The 
helper functions backend, post and backend, get make an HTTP POST/GET request to the 
merchant backend, respectively, with the given request body / query parameters. 


4.5.2 Back Office APIs 


The back office API allows the merchant to query information about the history and status of 
payments, as well as correlate wire transfers to the merchant's bank account with the respective 
GNU Taler payment. This API is necessary to allow integration with other parts of the merchant's 
e-commerce infrastructure. 


4.5.3 Example Merchant Frontends 


We implemented the following applications using the merchant backend API. 


Blog Merchant The blog merchant's landing page has a list of article titles with a teaser. When 
following the link to the article, the customer is asked to pay to view the article. 


Donations The donations frontend allows the customer to select a project to donate to. The 
fulfillment page shows a donation receipt. 


Codeless Payments The codeless payment frontend is a prototype for a user interface that allows 
merchants to sell products on their website without having to write code to integrate with 
the merchant backend. Instead, the merchant uses a web interface to manage products and 
their available stock. The codeless payment frontend then creates an HTML snippet with a 
payment button that the merchant can copy-and-paste integrate into their storefront. 


Mhttp://flask.pocoo.org/ 
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@app. route ("/donate" ) 
def donate (): 
donation amount = expect parameter("donation amount") 
donation, donor = expect parameter ("donation donor") 
fulfillment url = flask.url for("fulfillment", _external=True) 
order - dict( 
amount-donation, amount, 
extra-dict(donor-donation donor, amount-donation, amount), 
fulfillment. url-fulfillment url, 
summary-" Donation, to, the, GNU Taler project", 


) 

* ask backend to create new order 

order resp = backend post("order", dict(order-order)) 

order id = order resp["order id"] 

return flask.redirect(flask.url for("fulfillment", order id-order id)) 


Gapp.route("/receipt") 

def fulfillment (): 
order id = expect parameter("order id") 
pay .params = dict(order id-order. id) 


# ask backend for status of payment 
pay_status = backend get("check-payment", pay params) 


if pay status.get(" payment redirect url"): 
return flask.redirect(pay. status[" payment redirect url"]) 


if pay status.get(" paid"): 

* The "extra" field in the contract terms can be used 

# by the merchant for free-form data, interpreted 

# by the merchant (avoids additional database access) 

extra = pay_status["contract_terms"]["extra"] 

return flask .render_template ( 
"templates/fulfillment.html", 
donation_amount=extra["amount" ], 
donation_donor=extra["donor"], 
order_id=order_id, 
currency -CURRENCY) 


# no pay redirect but article not paid, this should never happen! 
err abort(500, message-"Internal, error ,, invariant, failed", json-pay. status) 


Figure 4.10: Code snippet with core functionality of a merchant frontend to accept donations. 
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Figure 4.11: Architecture of the wallet reference implementation 


Survey The survey frontend showcases the tipping functionality of GNU Taler. The user fills out 
a survey and receives a tip for completing it. 


Back office The example back-office application shows the history and status of payments pro- 
cessed by the merchant. 


The code for these examples is available at https: //git.taler.net/|n the repositories 


blog, donations, codeless, survey and backoffice respectively. 


4.6 Wallet 


The wallet manages the customer's reserves and coins, lets the customer view and pay for 
contracts from merchants. It can be seen in operation in Section [ı.3] 

The reference implementation of the GNU Taler wallet is written in the TypeScript language 
against the WebExtension APF?} a cross-browser mechanism for browser extensions. The reference 
wallet is a “tightly integrated” wallet, as it directly hooks into the browser to process responses 
with the HTTP status code “402 Payment Required”. 

Many cryptographic operations needed to implement the wallet are not commonly available 
in a browser environment. We cross-compile the GNU Taler utility library written in C as well as 
its dependencies (such as libgcrypt) to asm.js (and WebAssembly on supported platforms) using 
the LLVM-based emscripten toolchain [Zak11]. 

Cryptographic operations run in an isolated process implemented as a WebWorker[5] This 
design allows the relatively slow cryptographic operations to run concurrently in the background 
in multiple threads. Since the crypto WebWorkers are started on-demand, the wallet only uses 
minimal resources when not actively used. 


https://html.spec.whatwg.org 
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4.6.1 Optimizations 


To improve the perceived performance of cryptographic operations, the wallet optimistically 
creates signatures in the background while the user is looking at the “confirm payment” dialog. 
If the user does not accept the contract, these signatures are thrown away instead of being sent to 
the merchant. This effectively hides the latency of the most expensive cryptographic operations, 
as they are done while the user consciously needs to make a decision on whether to proceed with 
a payment. 


4.6.2 Coin Selection 


The wallet hides the implementation details of fractionally spending different denomination from 
the user, and automatically selects which denominations to use for withdrawing a given amount, 
as well as which existing coins to (partially) spend for a payment. 

Denominations for withdrawal are greedily selected, starting with the largest denomination 
that fits into the remaining amount to withdraw. Coin selection for spending proceeds similarly, 
but first checks if there is a single coin that can be partially spent to cover the whole amount. 
After each payment, the wallet automatically refreshes coins with a remaining amount large 
enough to be refreshed. We discuss a simple simulation of the current coin selection algorithm in 
Section [4.8.2] 

A more advanced coin selection would also consider the fee structure of the exchange, 
minimizing the number of coins as well as the fees incurred by the various operations. The 
wallet could additionally learn typical amounts that the user spends, and adjust withdrawn 
denominations accordingly to further minimize costs. An opposing concern to the financial cost 
is the anonymity of customers, which is improved when the spending behavior of wallets is as 
similar as possible. 


4.6.3 Wallet Detection 


When websites such as merchants or banks try to signal the Taler wallet—for example, to request 
a payment or trigger reserve creation—it is possible that the customer simply has no Taler wallet 
installed. To accommodate for this situation in a user-friendly way, the HTTP response containing 
signaling to wallet should contain as response body an HTML page with (1) a taler: link to 
manually open loosely integrated wallets and (2) instructions on how to install a Taler wallet if 
the user does not already have one. 

It might seem useful to dynamically update page content depending on whether the Taler 
wallet is installed, for example, to hide or show a "Pay with Taler" or “Withdraw to Taler wallet" 
option. This functionality cannot be provided in general, as only the definitive presence of a 
wallet can be detected, but not its absence when the wallet is only loosely integrated in the user's 
browser via a handler for the taler: URI scheme. 

We nevertheless consider the ability to know whether a customer has definitely installed a 
Taler wallet useful (if only for the user to confirm that the installation was successful), and expose 
two APIs to query this. The first one is JavaScript-based and allows to register a callback for 
the when presence/absence of the wallet is detected. The second method works without any 
JavaScript on the merchant's page, and uses CSS to dynamically show/hide element 
on the page marked with the special taler-installed-show and taler-installed-hide 
CSS classes, whose visibility is changed when a wallet browser extension is loaded. 

Browser fingerprinting is a concern with any additional APIs made available to 
websites, either by the browser itself or by browser extensions. Since a website can simply try 
to trigger a payment to determine whether a tightly integrated Taler wallet is installed, one bit 
of additional fingerprinting information is already available through the usage of Taler. The 
dynamic detection methods do not, however, expose any information that is not already available 
to websites by signaling the wallet through HTTP headers. 
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4.6.4 Backup and Synchronization 


While users can manually import and export the state of the wallet, at the time of writing this, 
automatic backup and synchronization between wallets is not implemented yet. We discuss the 
challenges with implementing backup and synchronization in a privacy-preserving manner in 


Chapter 


4.6.5 Wallet Liquidation 


If a customer wishes to stop using GNU Taler, they can deposit the remaining coins in their wallet 
back to their own bank account. We call this process liquidation. 

In deployments with relatively lenient KYC regulation, the normal deposit functionality 
used by merchants is used for wallet liquidation. The wallet simply acts as a merchant for one 
transaction, and asks the exchange to deposit the coins into the customer's bank account. 

However in deployments with strict KYC regulations, the customer would first have to register 
and complete a KYC registration procedure with the exchange. To avoid this, liquidation can be 
implemented as a modified deposit, which restricts the payment to the bank account that was 
used to create a reserve of the customer. 

The exchange cannot verify that a coin that is being liquidated actually originated the reserve 
that the customer claims it originated from, unless the user reveals the protocol transcripts for 
withdrawal and refresh operations on that coin, violating their privacy. Instead, each reserve 
tracks the amount that was liquidated into it, and the exchange rejects a liquidation request if the 
liquidated amount exceeds the amount that was put into the reserve. Note that liquidation does 
not refill the funds of a reserve, but instead triggers a bank transfer of the liquidated amount to 
the bank account that created the reserve. 


4.6.6 Wallet Signaling 


We now define more precisely the algorithm that the wallet executes when a website signals 
to that wallet that an operation related to payments should be triggered, either by opening a 
taler:pay URL or by responding with HTTP 402 and at least one Taler-specific header. 

The steps to process a payment trigger are as follows. The algorithm takes the following 
parameters: current, url (the URL of the page that raises the 402 status or nul 1 if triggered by a 
taler:pay URL), contract, url, resource url, session id,offer url,refund url, 
tip token (from the “Taler-...” headers or taler:pay URL parameters respectively) 


1. If resource url a non-empty string, set target. urlto resource url, otherwise set 
target url to current url. 


2. If target url is empty, stop. 


3. If there is an existing payment p whose fulfillment URL equals target. url and either 
current, url is null or current url has the same origin as either the fulfillment URL 
or payment URL in the contract terms, then: 


3.1. If session idis non-empty and the last session ID for payment p was recorded in 
the wallet with session signature sig, construct a fulfillment instance URL from sig and 
the order ID of p. 


3.2. Otherwise, construct an extended fulfillment URL from the order ID of p. 


3.3. Navigate to the extended fulfillment URL constructed in the previous step and stop. 


4. If contract url is a non-empty URL, execute the steps for processing a contract URL 
(with session id)and stop. 


5. If of fer_url is a non-empty URL, navigate to it and stop. 
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6. If re£und url is a non-empty URL, process the refund and stop. 
7. If tip_url is a non-empty URL, process the tip and stop. 


For interactive web applications that request payments, such as games or single page apps 
(SPAs), the payments initiated by navigating to a page with HTTP status code 402 are not 
appropriate, since the state of the web application is destroyed by the navigation. Instead the wallet 
can offer a JavaScript-based API, exposed as a single function with a subset of the parameters of the 
402-based payment: contract_url, resource_url, session_id refund_url, offer_url, 
tip_token. Instead of navigating away, the result of the operation is returned as a JavaScript 
promise (either a payment receipt, refund confirmation, tip success status or error). If user input 
is required (e.g., to ask for a confirmation for a payment), the page’s status must not be destroyed. 
Instead, an overlay or separate tab/window displays the prompt to the user. 


4.7 Cryptographic Protocols 


In this section, we describe the main cryptographic protocols for Taler in more detail. The more 
abstract, high-level protocols from Section]3.5.1|are instantiated and and embedded in concrete 
protocol diagrams that can hopefully serve as a reference for implementors. 

For ease of presentation, we do not provide a bit-level description of the cryptographic 
protocol. Some details from the implementation are left out, such as fees, additional timestamps 
in messages and checks for the expiration of denominations. Furthermore, we do not specify the 
exact responses in the error cases, which in the actual implementation should include signatures 
that could be used during a legal dispute. Similarly, the actual implementation contains some 
additional signatures on messages sent that allow to prove to a third party that a participant did 
not follow the protocol. 

As we are dealing with financial transactions, we explicitly describe whenever entities need to 
safely write data to persistent storage. As long as the data persists, the protocol can be safely 
resumed at any step. Persisting data is cumulative, that is an additional persist operation does 
not erase the previously stored information. 

The implementation also records additional entries in the exchange's database that are needed 
for auditing. 


4.7.1 Preliminaries 


In our protocol definitions, we write check COND to abort the protocol with an error if the 
condition COND is false. 
We use the following algorithms: 


* Ed25519.Keygen() — (sk, pk) to generate an Ed25519 key pair. 

* Ed25519.GetPub(sk) — pk to derive the public key from an Ed25519 public key. 

* Ed25519.Sign(sk, m) — c to create a signature 7 on message m using secret key sk. 

e Ed25519.Verify(pk, c, m) ++ b to check if c is a valid signature from pk on message m. 


* HKDF(n,k,s) — m is the HMAC-based key derivation function [KE10|, producing an 
output m of n bits from the input key material k and salt s. 


We write Z5, for the multiplicative group of integers modulo N. Given an r € ZX, we write 
r71 for the multiplicative inverse modulo N of r. 

We write H (1) for the SHA-512 hash of a bit string. 

We write FDH(N, m) for the full domain hash that maps the bit string m to an element of 
ZN. Specifically, FDH(N, m) is computed by first computing H(m). Let b :— [ log, N]. The full 
domain hash is then computed by iteratively computing a HKDF to obtain b bits of output until 
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the b-bit value is below N. The inputs to the HKDF are a "secret key", a fixed context plus a 16-bit 
counter (in big endian) as a context chunk that is incremented until the computation succeeds. 
For the source key material, we use a binary encoding of the public RSA key with modulus N 
Here, the public RSA key is encoded by first expressing the number of bits of the modulus and 
the public exponent as 16-bit numbers in big endian, followed by the two numbers (again in 
unsigned big endian encoding)[?] For the context, the C-string “RSA-FDA FTpsW!” (without 
o-termination) is used. For the KDE, we instantiate the HKDF described in RFC 5869 
using HMAC-SHA512 as XTR and HMAC-SHA256 as PRE] Let the result of the first successful 
iteration of the HKDF function be r with 0 < r < N. Then, to protect against a malicious exchange 
when blinding values, the FDH(N, m) function checks that gcd (r, n) = 1. If not, the FDH (n, m) 
calculation fails because n is determined to be malicious. 

The expression x + X denotes uniform random selection of an element x from set X. We 
use SelectSeeded(s, X) — x for pseudo-random uniform selection of an element x from set X and 
seed s. Here, the result is deterministic for fixed inputs s and X. 

The exchange's denomination signing key pairs ( (skD;, pkD;) } are RSA keys pairs, and thus 
pkD; = (ei, Nj), skD; = d;i. We write D(pkD;) for the financial value of the denomination pkD;. 


4.7.2. Withdrawing 


The withdrawal protocol is defined in Figure 1.12] The following additional algorithms are used, 
which we only define informally here: 


e CreateBalance(W,,v) ++ L is used by the exchange, and has the side-effect of creating a 
reserve record with balance v and reserve public key (effectively the identifier of the reserve) 
W,. 

P 


* GetWithdrawR(p) > {1,7 c} is used by the exchange, and checks if there is an existing 
withdraw request p. If the existing request exists, the existing blind signature vc over coin 
C is returned. On a fresh request, -L is returned. 


e BalanceSufficient(Ws, pkD;) — b is used by the exchange, and returns true if the balance in 
the reserve identified by W; is sufficient to withdraw at least one coin if denomination pkD,. 


e DecreaseBalance(Ws, pkD;) > L is used by the exchange, and decreases the amount left in 
the reserve identified by W; by the amount D(pkD;) that the denomination pkD, represents. 


4.7.3 Payment transactions 


The payment protocol is defined in two parts. First, the spend protocol in Figure [4-13] defines 
the interaction between a merchant and a customer. The customer obtains the contract terms (as 
pp) from the merchant, and sends the merchant deposit permissions as a payment. The deposit 
protocol in Figure [4.14] defines how subsequently the merchant sends the deposit permissions 
to the exchange to detect double-spending and ultimately to receive a bank transfer from the 
exchange. 

Note that in practice the customer can also execute the deposit protocol on behalf of the 
merchant. This is useful in situations where the customer has network connectivity but the 
merchant does not. It also allows the customer to complete a payment before the payment 
deadline if a merchant unexpectedly becomes unresponsive, allowing the customer to later prove 
that they paid on time. 

We limit the description to one exchange here, but in practice, the merchant communicates 
to the customer the exchanges that it supports, in addition to the account information Ay that 
might differ between exchanges. 


14S0 technically, it is FDH(N, e, m), but we use the simplified notation FDH(N, m). 
15See GNUNET, CRYPTO rsa public key encode(). 


16As suggested inhttp://eprint.iacr.org/2010/264.pdf 
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Customer 
Knows ((ej, Nj) } = {pkD;} 


(ws, Wp) + Ed25519.Keygen() 


Persist reserve (ts, v) 


Choose t with pkD, € {pkD;} 
(Cs, Cp) + Ed25519.Keygen() 
re ZN 


Persist planchet (cs, r) 


m := FDH(N;, Cp) - r! mod N; 
Pw :— (pkD;, m) 
Ow := Ed25519.Sign(w;, pw) 


Bank transfer 


p:— (Wp, Ow, Pw) 


Exchange 
Knows { (skD;, pkD;) } 


(subject: Wy, amount: v) 


CreateBalance(W,, v) 


check pkD; € {pkD;} 
check Ed25519.Verify (W,, pw, 0w) 
x — GetWithdraw(p) 
ifr= 1 
check BalanceSufficient(W,, pkD;) 
DecreaseBalance(W;, pkD;) 
Persist withdrawal p 
Tc :— (mi)?! mod N; 


else 


ge := rio 


> 


check 0 =n, FDH(N;, Cp) 
Persist coin (pkD;, Cs, Cp, 0c) 


Figure 4.12: Withdrawal protocol diagram. 
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We use the following algorithms, defined informally here: 


SelectPayCoins(v, Em) > {(coin;, fj) ) selects fresh coins (signed with denomination keys 
from exchange Ey) to pay for the amount v. The result is a set of coins together with the 
fraction of each coin that must be spent such that the amounts contributed by all coins sum 
up to v. 


MarkDirty(coin, f) > L subtracts the fraction f from the available amount left on a coin, 
and marks the coin as dirty (to trigger refreshing in case f is below the denomination value). 
Thus, assuming the coin has any residual value, the customer's wallet will do a refresh on 
coin and not use it for further payments. This provides unlinkability of transactions made 
with change arising from paying with fractions of a coin's denomination. 


Deposit(Em, Di) > b executes the second part of the payment protocol (i.e., the deposit) 
with exchange Ey, using deposit permission Dj. 


GetDeposit(C,, h) > 1-L, p(p,;;) checks in the exchange's database for an existing processed 
deposit permission on coin C; for the contract identified by h. The algorithm returns the 
existing deposit permission pp ;), or -L if a matching deposit permission is not recorded. 


IsOverspending(Cpy, pkD, f) — b checks in the exchange's database if there if at least the 
fraction f of the coin C, of denomination pkD is still available for use, based on existing 
spend / withdraw records of the exchange. 


MarkFractionalSpend(Cy, f) ++ -L adds a spending record to the exchanges database, indicat- 
ing that fraction f of coin C; has been spent (in addition to existing spending/refreshing 
records). 


ScheduleBankTransfer(A m, f, pkD, hc) > L schedules a bank transfer from the exchange to 
the account identified by A y, for subject h; and for the amount f - D(pkD). 


4.7.4 Refreshing and Linking 


The refresh protocol is defined in Figures[4.16|and [4.17] The refresh protocol allows the customer 
to obtain change for the remaining fraction of the value of a coin. The change is generated as a 
fresh coin that is unlinkable to the dirty coin to anyone except for the owner of the dirty coin. 

A naive implementation of a refresh protocol that just gives the customer a new coin could be 
used for peer-to-peer transactions that hides income from tax authorities. Thus, (with probability 
(1 — 1/x)) the refresh protocol records information that allows the owner of the original coin to 
obtain the refreshed coin from the original coin via the linking protocol (illustrated in Figure 4.18). 
We use the following algorithms, defined informally here: 


RefreshDerive is defined in Figure 1.15] 


GetOldRefresh(prc) > 1.L, y} returns the past choice of y if pre is a refresh commit message 
that has been seen before, and L otherwise. 


IsConsistentChallenge(prc, y) > {-L, T ) returns T if no refresh-challenge has been persisted 
for the refresh operation by commitment prc or y is consistent with the persisted (and thus 
previously received) challenge; returns 1 otherwise. 


LookupLink(C,) +> ((p, of), a} looks up refresh records on coin with public key C, in 
the exchange's database and returns the linking message p? , linking signature cb 
blinded signature gË for each refresh record i. 


and 
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Customer Merchant 
Knows pkM Knows (pkM, skM) 
Select product/service 
DAE fe Se Sa EO SUR > 
Determine: 
e v (price) 


e Ey (exchange) 
e Ay (acct.) 


e info (free-form details) 


Request payment 


(Ps, Pp) €- Ed25519.Keygen() 


Persist ownership identifier ps 


pp := (Em, Am, pkM, H((v, info) ), Py) 
op := Ed25519.Sign(skM, pp) 


Pp, Cp, V, info 


(M, Am, pkM, h’, P) = Pp 

check Ed25519.Verify(pkM, op, pp) 
2 

check P, = P, 


check /ı' = H((v, info)) 
cf — SelectPayCoins(v, Em) 
for (coin;, fi) € cf 
MarkDirty (coin;, f;) 
(Cs, Cp, pkD, ac) := coin; 
Pis) := (Cp, PKD, 0c, fi, H(pp), Am, PKM) 
OD) := Ed25519.Sign(cs, p(pj) 


Persist (op, cf, PP, pip), 0 (pj); 0, info) 


for DiE D 
check Deposit (Ej, D;) 


Figure 4.13: Spend Protocol executed between customer and merchant for the purchase of an 
article of price v using coins from exchange Em. The merchant has provided his account details 
to the exchange under an identifier Ay. The customer can identify themselves as the one who 
received the offer using ps. 
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Customer/Merchant Exchange 

Knows pkESi Knows skESig, pkESig, { pkD; 
g i 

Knows D; = (pj, 0(p,)) 


Poyo) = Di 
(Cp, pkD, oc, fi, h, Am, pkM) :— p(p,i) 
check pkD € {pkD;} 
(e, N) := pkD 
check Ed25519.Verify(Cp, 0(p i), 0(D,i)) 
x €— GetDeposit (Cy, h) 
i£xil 
check 0% =) FDH(N, Cp) 
check —IsOverspending (Cy, pkD, f) 
Persist deposit-record D; 
MarkFractionalSpend(Cp, f) 
ScheduleBankTransfer(A y, f, pkD, hc) 
else 
check x = PDA) 
opc + Ed25519.Sign(pkESig, p(p j)) 


[DC 


check Ed25519.Verify 
(pkESig, "pc, P(D,i)) 


Figure 4.14: Deposit Protocol run for each deposited coin D; € D with the exchange that signed 
the coin. 


RefreshDerive(s, (e, N), Cp) 


t := HKDF(256,s, "t ") 

T := Curve25519.GetPub(t) 
x :— ECDH-EC(t, Cp) 

r := SelectSeeded(x, Ziv) 
cs := HKDF(256, x, "c") 
C, := Ed25519.GetPub(c;) 
m:=r°-Cy mod N 


return (f, T, x, cs, Cy, î) 


Figure 4.15: The RefreshDerive algorithm running with the seed s on dirty coin C, to generate a 
fresh coin to be later signed with denomination key pkD :— (e, N). 
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Customer 
Knows (pkD; 
Knows coing = (pkDo, c c gg 


Select (Ni, e+) := pkD, € {pkD,} 


fori=1,...,« 
si È (oi) 


X; := RefreshDerive(s;, pkD;, ci 


(ip Tape’ CP mm) = X 
hr := H(Tı,...,Tç) 
hg :— H(M,..., Mx) 
hc := H(hi, lm) 


oo) 


Orc := Ed25519.Sign(c(?, prc) 


Persist refresh-request (pac, Rc) 


prc := (hc, pkD;, pkDo, C 


PRC ORC 


Y 


Exchange 
Knows ((skD;, pkD;) } 


(hc, pkD;, pkDo, CP’, e) := pre 
check Ed25519.Verify(C\”, orc, prc) 
x «— GetOldRefresh(prc) 
ifx 1 

v := D(pkD;) 

(eo, No) := pkDo 

check ~lIsOverspending(C’, pkDo, v) 

check pkD, € {pkD;} 

check FDH(No, C®) =n, (0/0 y 

MarkFractionalSpend(C/(”, v) 

Y & {1,...,«} 

Persist refresh-record (prc, y) 
else 


y:—x 


Figure 4.16: Refresh Protocol (Commit Phase) 


92 


CHAPTER 4. IMPLEMENTATION OF GNU TALER 


Customer Exchange 


check IsConsistentChallenge(pnc, y) 
Persist refresh-challenge (onc, y) 

S = (Sly Sy 5 S 1) Sk) 

PL = (ce, pkD,, Ty, my) 

prr = (Ty, Tî, S) 

0, = Ed25519.Sign(c, p; ) 


PRR, PL, OL 


(T5, Tî, S) := PRR 
($1, 84 1 Sy 41s +++ 8k)) = 8 
check Ed25519.Verify(C\”, rı, p1) 
fori = 1,...,y—1l,y+1,...,K 

Xj:— RefreshDerive(s;, pkD,, C\”) 

(ti, Ti xi, cU), CH ,mı) := X; 
hry = H(Tı,...,T,_ı, Th, O Te) 
hz = Hf, . .., Wis a, D, as. .., Mg) 


hc = H(hr, hin) 


Û 
check hic = hç 


zx) .— --skDı 
Uc =m 


check (c£ ye Iu ci» 


Persist coin (pkD,, c, ca) 


Figure 4.17: Refresh Protocol (Reveal Phase) 


4.7. CRYPTOGRAPHIC PROTOCOLS 


Customer Exchange 


Knows coing = (pkDo, cU, cP, gy 


e 


L:= LookupLink(C\”” ) 


ao) eı 


( 
(C, pko TË, m) == gf 
(£9, NP :- pof 


a) 2. (0) 
check Cp =C 
check Ed25519.Verify(C, p\”, o(”) 


x; :— ECDH (c9, T) 
rj := SelectSeeded(x;, Zw, ) 


c := HKDF(256, x;, "c") 
CÛ) := Ed25519.GetPub(c!”) 
of) := (1) 7 . ml) 


(i) 
j Cp 


i), olf) 2 
check (eye c) 


(Re-)obtain coin (pkD(?, ce, e cQ 


Figure 4.18: Linking protocol 
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4.7.5 Refunds 


The refund protocol is defined in Figure 4.19] The customer requests from the merchant that a 
deposit should be “reversed”, and if the merchants allows the refund, it authorizes the exchange 
to apply the refund and sends the refund confirmation back to the customer. Note that in practice, 
refunds are only possible before the refund deadline, which is not considered here. 

We use the following algorithms, defined informally here: 


* ShouldRefund(pp,m) ++ {T, L} is used by the merchant to check whether a refund with 
reason m should be given for the purchase identified by the contract terms pp. The decision 
is made according to the merchant's business rules. 


LookupDeposits(pp, m) ++ 1(0(p,i), 0(p)) is used by the merchant to retrieve deposit per- 
missions that were previously sent by the customer and already deposited with the exchange. 


Refund Deposit(Cp, h, f, pkM) is used by the exchange to modify its database. It (partially) 
reverses the amount f of a deposit of coin C; to the merchant pkM for the contract identified 


by h. The procedure is idempotent, and subsequent invocations with a larger f increase the 
refund. 
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Customer Merchant 
Knows pkM, pkESig Knows (pkM, skM), pkESig 
nen eee Or reid ee 
(Payment pp, reason m) 
check ShouldRefund(pp, m) 
DEL TEE EREMO ERR BEER Execute refund esit na hehehe We xi aê eae wlan n eda dê ee HAAA ET 
Exchange Merchant 


Knows (skESig, pkESig) 
for (0(p,i),') € LookupDeposits(pp) 


P(Xi) = ("refund”, pp) 
C(X,i) = Ed25519.Sign(skM, p(x,;)) 


X := [xy x,y} 


for (p(x i) 0(x,)) € X 
check ("refund",pp) :— px 
check (Cy, pkD, ac, f,h, Am, pkM) := pp 
check Ed25519.Verify(pkM, px, 7x) 
RefundDeposit(C),h, f, pkM) 
(xci) := ("refunded”, pp) 
C(xcjj) := Ed25519.Sign(skESig, p(xc,;) 


XC := leixci (xc) 


Customer Merchant 


XC 


for (P(x) "(xc,)) € XC 
check Ed25519.Verify(pkESig, 0(xc,i),9(xc,i)) 


Figure 4.19: Refund protocol 
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Operation Time (ms) Operation Time (ms) 
eddsa create 9.69 eddsa create 34.80 
eddsa sign 22.31 eddsa sign 78.55 
eddsa verify 19.28 eddsa verify 72.50 
hash big 0.05 hash big 0.51 
hash small 0.13 hash small 1.37 
rsa 2048 blind 3-35 rsa 2048 blind 14.35 
rsa 2048 unblind 4.94 rsa 2048 unblind 19.78 
rsa 2048 verify 1.97 rsa 2048 verify 9.10 
rsa 4096 blind 10.38 rsa 4096 blind 47.86 
rsa 4096 unblind 16.13 rsa 4096 unblind 69.91 
rsa 4096 verify 6.57 rsa 4096 verify 29.02 


(a) Wallet microbenchmark on a Laptop (In- (b) Wallet microbenchmark on Android 
tel i7-4600U) with Firefox Moto G3 with Firefox 


Table 4.1: Wallet microbenchmarks 


4.8 Experimental results 


We now evaluate the performance of the core components of the reference implementation of 
GNU Taler. No separate benchmarks are provided for the merchant backend, as the work done by 
the merchant per transaction is relatively negligible compared to the work done by the exchange, 
and one exchange needs to provide service many merchants and all of their customers. Thus, the 
exchange is the bottleneck for the performance of the system. 

We provide a microbenchmark for the performance of cryptographic operations in the wallet 
(Table [4.1] Even on a low-end smartphone device, the most expensive cryptographic operations 
remain well under 150ms, a threshold for user-interface latency under which user happiness and 
productivity is considered to be unaffected [TASo6]. 

We implemented a benchmarking tool that starts a single (multi-threaded) exchange and a 
bank process for the taler-test wire transfer protocol. It then generates workload on the exchange 
with a configurable number of concurrent clients and operations. The benchmarking tool is able 
to run the exchange on a different machine (via SSH") than the benchmark driver, mock bank 
and clients. At the end, the benchmark outputs the number of deposited coins per second and 
latency statistics. 


4.8.1 Hardware Setup 


We used two server machines (£irefly and gv) with the following hardware specifications for 
our tests: 


* firefly has a 96-core AMD EPYC 7451 CPU and 256GiB DDR42667 MHz RAM. 

* gv has a 16-core Intel(R) Xeon X5550 (2.67GHz) CPU and 128GiB DDR31333 MHz RAM. 

We used 2048-bit RSA denomination keys for all of our exchange benchmarks. We used a 
development version of the exchange (with git commit hash 5fbda2gb76c24d...). PostgreSQL 


version 11.3 was used as the database. As our server machines have only slower hard-disk drives 
instead of faster solid-state drives, we ran the benchmarks with an in-memory database. 


Thttps://www.openssh.com/ 
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4.8.2 Coins Per Transaction 


The transaction rate is an important characteristic of a payment system. Since GNU Taler internally 
operates on the level of coins instead of transactions, we need to define what actually consititutes 
one transaction in our measurements. This includes both how many coins are used per transaction 
on average, as well as how often refresh operations are run. 

We ran a simple simulation to determine rather conservative upper bounds for the parameters 
that characterize the average transaction. 

In the simulation, thirteen denominations of values 2°,..., are available. Customers 
repeatedly select a random value to be spent between 4 and 5000. When customers do not have 
enough coins for a transaction, they withdraw a uniform random amount between the minimum 
amount to complete the transaction and 10000. The denominations selected for withdrawal are 
chosen by greedy selection of the largest possible denomination. When spending, the customer 
first tries to use one coin, namely the smallest coin larger than the requested amount. If no such 
coin exists in the customer’s wallet, the customer pays with multiple coins, spending smallest 
coins first. 

Choosing a random uniform amount for withdrawal could be considered unrealistic, as 
customers in practice likely would select from a fixed list of common withdrawal amounts, just 
like most ATMs operate. Thus, we also implemented a variation of the simulation that withdraws 
a constant amount of 1250 (i.e., 1/4 of the maximum transaction value) if it is sufficient for the 
transaction, and the exact required amount otherwise. 

We obtained the following results for the number of average operations executed for one 
“business transaction”: 


212 


random withdraw constant withdraw 


#spend operations 8.3 7.0 
#refresh operations 1.3 0.51 
#refresh output coins 4.2 3.62 


Based on these results, we chose the parameters for our benchmark: for every spend operation 
we run a refresh operation with probability 1/10, where each refresh operation produces 4 output 
coins. In order to arrive at the transaction rate, the rate of spend operations should be divided by 
10. 

Note that this is a rather conservative analysis. In practice, the coin selection for with- 
drawal/spending can use more sophisticated optimization algorithms, rather than using greedy 
selection. Furthermore, we expect that the amounts paid in real-world transactions will have more 
predictable distributions, and thus the offered denominations can be adjusted to typical amounts. 


Baseline Sequential Resource Usage 


To obtain a baseline for the resource usage of the exchange, we ran the benchmark on firefly 
with a single client that executes sequential requests to withdraw and spend 10000 coins, with 
10% refresh probability. 

Table [4.2] shows the time used for cryptographic operations, together with the number of 
times they are executed by the clients (plus the mock bank and benchmark setup) and exchange, 
respectively. Note that while we measured the wall-clock time for these operations, the averages 
should correspond to the actual CPU time required for the respective operations, as the benchmark 
with one client runs significantly fewer processes/threads than the number of available CPUs on 
our machine. 

The benchmark completed in 15.10 minutes on firefly. We obtained the total CPU usage of 
the benchmark testbed and exchange. The refresh operations are rather slow in comparison to 
spends and deposits, as the benchmark with a refresh probability of 0% only took 8.84 minutes to 
complete. 
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Operation Time/Op (us) Count (exchange) Count (clients) 
ecdh eddsa 1338.62 2430 3645 
ecdhe key create 1825.38 0 3645 
ecdhe key get public 1272.64 2430 4860 
eddsa ecdh 1301.78 0 4860 
eddsa key create 1896.27 0 12 180 
eddsa key get public 1729.69 9720 80 340 
eddsa sign 5182.33 13393 25 608 
eddsa verify 3976.96 25586 25 627 
hash 1.41 165 608 169 445 
hash context finish 0.28 1215 1227 
hash context read 0.81 25515 25 655 
hash context start 11.38 1215 1227 
hkdf 40.61 65057 193 506 
rsa blind 695.25 9720 31 633 
rsa private key get public 5.30 0 40 
rsa sign blinded 5284.88 17053 0 
rsa unblind 1348.62 0 21 898 
rsa verify 421.19 13393 29216 


Table 4.2: Cryptographic operations in the benchmark with one client and 10000 operations. 


Relation Table (MiB) Indexes (MiB) Total (MiB) 
denominations 0.02 0.03 0.05 
reserves in 0.01 0.08 0.09 
reserves 0.02 0.25 0.27 
refresh. commitments 0.36 0.28 0.64 
refresh transfer keys 0.38 0.34 0.73 
refresh, revealed, coins 4.19 0.91 5.14 
known. coins 7.37 0.70 8.07 
deposits 4.85 6.80 11.66 
reserves out 8.95 4.48 13.43 


Sum 26.14 13.88 40.02 


Table 4.3: Space usage by database table for 10000 deposits with 10% refresh probability. 
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The size of the exchange’s database after the experiment (starting from an empty database) is 
shown in Table [4.3] We measured the size of tables and indexes using the pg_relation_size / 
pg_indexes_size functions of PostgreSQL. 


We observe that even though the refresh operations account for about half of the time taken by 
the benchmark, they contribute to only ~ 16% of the database’s size. The computational costs for 
refresh are higher than the storage costs (compared to other operations), as the database stores 
only needs to store one commitment, one transfer key and the blinded coins that are actually 
signed. 

In our sequential baseline benchmark run, only one reserve was used to withdraw coins, and 
thus the tables that store the reserves are very small. In practice, information for multiple reserves 
would be tracked for each active cutomers. 


The TCP/IP network traffic between the exchange, clients and the mock bank was 57.95 MiB, 
measured by the Linux kernel’s statistics for transmitted /received bytes on the relevant network 
interface. As expected, the traffic is larger than the size of the database, since some data (such as 
signatures) is only verified/generated and not stored in the database. 


4.8.3 Transaction Rate and Scalability 


Figure [4.20] shows the mean time taken to process one coin for different numbers of parallel 
clients. With increasing parallelism, the throughput continues to rise roughly until after the 
number of parallel clients saturates the number of available CPU cores (96). There is no significant 
decrease in throughput even when the system is under rather high load, as clients whose requests 
cannot be handled in parallel are either waiting in the exchange's listen backlog or waiting in a 
retry timeout (with randomized, truncated, exponential back-off) after being refused when the 
exchange's listen backlog is full. 


Figure shows the CPU time (sum of user and system time) of both the exchange and 
the whole benchmark testbed (including the exchange) in relation to the wall-clock time the 
benchmark took to complete. We can see that the gap between the wall-clock time and CPU time 
used by the benchmark grows with an increase in the number of parallel clients. This can be 
explained by the CPU usage of the database (whose CPU usage is not measured as part of the 
benchmark). With a growing number of parallel transactions, the database runs into an increasing 
number of failed commits due to read/write conflicts, leading to retries of the corresponding 
transactions. 


To estimate the time taken up by cryptographic operations in the exchange, we first measured 
a baseline with a single client, where the wall-clock time for cryptographic operations is very 
close to the actual CPU time, as virtually no context switching occurs. We then extrapolated these 
timings to experiment runs with parallelism by counting the number of times each operation is 
executed and multiplying with the baseline. As seen in the dot-and-dash line in Figure[4.21] by 
our extrapolation slightly more than half of the time is spent in cryptographic routines. 


We furthermore observe in Figure[4.21]that under full load, less than 1/3 of the CPU time is 
spent by the exchange. A majority of the CPU time in the benchmark is used by the simulation of 
clients. As we did not have a machine available that is powerful enough to generate traffic that 
can saturate a single exchange running on firefly, we estimate the throughput that would be 
possible if the machine only ran the exchange. The highest rate of spends was 780 per second. 
Thus, the theoretically achievable transaction rate on our single test machine (and a dedicated 
machine for the database) would be 780 - 3/10 = 234 transactions per second under the relatively 
pessimistic assumptions we made about what constitutes a transaction. 

If a GNU Taler deployment was used to pay for items of fixed price (e.g., online news articles), 
the overhead of multiple coins and refresh operations (which accounts for ~ 50% of spent time as 
measured earlier) and multiple coins per payment would vanish, giving an estimated maximum 
transaction rate of 742 - 2 = 1484 transactions per second. 
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Figure 4.20: Coin throughput in relation to number of parallel clients, with 1000 coins per client 
per experiment run. 
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Figure 4.21: Comparison of real time, the CPU time for the exchange and the whole benchmark. 
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Base latency phe êwe 
Endpoint 100 ms delay 
(ms) 
(ms) 
/keys 1.14 201.25 
/reserve/withdraw 22.68 222.46 
/deposit 22.36 223.22 
/refresh/melt 20.71 223.9 
/refresh/reveal 63.64 466.30 


Table 4.4: Effects of 100 ms symmetric network delay on total latency. 


Request size Response size Request size Response size 


Endpoint 2048-bit RSA  2048-bit RSA 1024-bit RSA — 1024-bit RSA 
(kB) (kB) (kB) (kB) 
/keys 0.14 3.75 0.14 3.43 
/reserve/withdraw 0.73 0.71 0.60 0.49 
/deposit 1.40 0.34 1.14 0.24 
/refresh/melt 1.06 0.35 0.85 0.35 
/refresh/reveal 1.67 2.11 1.16 1.23 


Table 4.5: Request and response sizes for the exchange’s API. In addition to the sizes for 2048-bit 
RSA keys (used throughout the benchmark), the sizes for 1024-bit RSA keys are also provided. 


4.8.4 Latency 


We connected firefly and gv directly with a patch cable, and introduced artificial network 
latency by configuring the Linux packet scheduler with the tc tool. The goal of this experiment 
was to observe the network latency characteristics of the implementation. Note that we do 
not consider the overhead of TLS in our experiments, as we assume that TLS traffic is already 
terminated before it reaches the exchange service, and exchanges can be operated securely even 
without TLS. 

The comparison between no additional delay and a 100 ms delay is shown in Table TCP 
Fast Open was enabled on both gv and firefly. Since for all operations except 
/refresh/reveal, both request and response fit into one TCP segment, these operations 
complete within one round-trip time. This explains the additional delay of ~ 200ms when the 
artificial delay is introduced. Without TCP Fast Open, we would observe an extra round trip for 
the SYN and SYN/ACK packages without any payload. The /refresh/reveal operation takes 
an extra roundtrip due to the relatively large size of the request (as show in Table [4-5), which 
exceeds the MTU of 1500 for the link between gv and firefly, and thus does not fit into the 
first TCP Fast Open packet. 

Figure [4.22] shows the latency for the exchange's HTTP endpoints in relation to different 
network delays. As expected, the additional delay grows linearly for a single client. We note that 
in larger benchmarks with multiple parallel clients, the effect of additional delay would likely not 
just be linear, due to timeouts raised by clients. 


4.9 Current Limitations and Future Improvements 


Currently the auditor does not support taking samples of deposit confirmations that merchants 
receive. The API and user interface to receive and process proofs of misbehavior of the ex- 
change/ merchant generated by the wallet is not implemented yet. 

As a real-world deployment of electronic cash has rather high requirements for the operational 
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Figure 4.22: Effect of artificial network delay on exchange’s latency. 


security, the usage of hardware security modules for generation of signatures should be considered. 
Currently, a single process has access to all key material. For a lower-cost improvement that 
decreases the performance of the system, a threshold signature scheme could be used. 

The current implementation is focused on web payments. To use GNU Taler for payments 
in brick-and-mortar stores, hardware wallets and smartphone apps for devices with near-field- 
communication (NFC) must be developed. In some scenarios, either the customer or the merchant 
might not have an Internet connection, and this must be considered in the protocol design. In 
typical western brick-and-mortar stores, it is currently more likely that the merchant has Internet 
connectivity, and thus the protocol must allow operations of the wallet (such as refreshing) to 
be securely routed over the merchant’s connection. In other scenarios, typically in developing 
countries, the merchant (for example, a street vendor) might not have Internet connection. If the 
vendor has a smartphone, the connection to the merchant can be routed through the customer. 
In other cases, street vendors only have a “dumb phone” that can receive text messages, and 
the payment goes through a provider trusted by the merchant that sends text messages as 
confirmation for payments. All these possibilities must be considered both from the perspective 
of the procotol and APIs as well as the user experience. 

Our experiments were only done with single exchange process and a single database on the 
same machine. There are various ways to horizontally scale the exchange: 


* Multiple exchange processes can be run on multiple machines and access the database 
that runs a separate machine. Requests are directed to the machines running the exchange 
process via a load balancer. In this scenario, the throughput of the database is likely to be 
the bottleneck. 


* To avoid having the database as a bottleneck, the contents can be partitioned into shards. 
For this technique to be effective, data in the shards should not have any dependencies in 
other shards. A natural way to do sharding for the Taler exchange is to give each shard the 
sole responsibility for a subset of all available denominations. 


* If the transaction volume on one denomination is too high to handle for a single shard, 
transactions can be further partitioned based on the coin's public key. Each would main- 
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tain the database of spent/refreshed coins for a subset of all possible coin public keys. 
This approach has been suggested for a centrally-banked cryprocurrency by Danezis and 


Meiklejohn [DM16]. 
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Chapter 5 


Future Work 


We now discuss future work that builds upon the results presented so far. 


Standard Model 


Our current instantiation of the Taler protocol relies heavily on hash functions. Since the result by 
Canetti and others about the theoretical impossibility of securely instantiating protocols 
that rely on the random oracle assumption for their security, a vast amount of literature has been 
devoted to find instantiations of interesting protocols in the standard model [KM15]. The Taler 
protocol syntax could likely be also instantiated securely in the standard model, based existing 
on blind signature schemes in the standard model. The trade-off however is that while removing 
the random oracle assumption, typically other less well known assumptions must be made. 


Post-Quantum security 


The possibility of post-quantum computers breaking the security of established cryptographic 
primitives has lately received a lot of attention from cryptographers. While currently most 
schemes with post-quantum security are impractical, it might be worthwhile to further investigate 
their application to e-cash, based on existing work such as [Zha+18]. 


Applications to network incentives 


Some peer-to-peer networking protocols (such as onion routing [DMSo4]) do not have inherent 
incentives and rely on volunteers to provide infrastructure. In future work, we want to look at 
adding incentives in the form of Taler payments to a peer-to-peer networking platform such as 
GNUnet. 


Smart(er) Contracts and Auctions 


Contract terms in Taler are relatively limited. There are some interesting secure multiparty 
computations, such as privacy-preserving auctions that could be offered by exchanges as 
a fixed smart contract. This would allow a full privacy-preserving auction platform, as current 
auction protocols only output the winner of a privacy-preserving auction but do not address the 
required anonymous payments. 


Backup and Sync 


Synchronization of wallets between multiple devices is a useful feature, but a naive implemen- 
tation endangers privacy. A carefully designed protocol for backup and synchronization must 
make sure that the hosting service for the wallet’s data cannot collaborate with the exchange 
and merchants to deanonymize users or transactions. Thus when spending coins for a payment, 
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devices should not have to synchronously talk to their backup/sync provider. This creates the 
challenge of allocating the total available balance to individual devices in a way that fits the 
customer’s spending pattern, and only require synchronous communication at fixed intervals or 
when really necessary to re-allocate coins. 

Another possible approach might be to use Private Information Retrieval (PIR) to 
access backup and synchronization information. 


Machine-Verified Proofs 


We currently model only a subset of the GNU Taler protocol formally, and proofs are handwritten 
and verified by humans. A tool such as CryptoVerif [Blao7 can allow a higher coverage and 
computer-checked proofs, and would allow protocol changes to be validated in shorter time. 


Coin Restrictions / “Taler for Children” 


By designating certain denominations for different purposes, GNU Taler could be used to 
implement a very simple form of anonymous credentials [PZ11] CLo4], which then could be used 
to implement a Taler wallet specifically aimed at children, in order to teach them responsible and 
autonomous spending behavior, while granting them privacy and at the same time preventing 
them from making age-inappropriate purchases online, as the discretion of parents. 


Chapter 6 


Conclusion 


This book presented GNU Taler, an efficient protocol for value-based electronic payment systems 
with focus on security and privacy. While we believe our approach to be socially and economically 
beneficial, a technological impact analysis is in order prior to adopting new systems that have 
broad economic and socio-political implications. 

Currencies serve three key functions in society: 


1. As a unit for measurement of value, 
2. a medium of exchange, and 
3. a store of value. 


How do the various methods measure up to these requirements? 


6.1 Cryptocurrencies vs. Central-Bank-Issued Currencies 


Cryptocurrencies generally fail to achieve the required stability to serve as a reasonable unit 
of measurement (Figure [6-1]. The volatility of cyptocurrencies is caused by a combination of 
a lack of institutions that could intervene to dampen fluctuations and a comparatively limited 
liquidity in the respective markets. The latter is exacerbated by the limited ability of decentralized 
cryptocurrencies to handle large transaction volumes, despite their extreme levels of resource 
consumption. As a result, the utility of decentralized cryptocurrencies is limited to highly 
speculative investments and to the facilitation of criminal transactions. 


Figure 6.1: Historical market price (in USD) of Bitcoin across major exchanges (Source: https 1 
//blockchain. com). 


107 


108 CHAPTER 6. CONCLUSION 


With respect to privacy, completely decentralized cryptocurrencies provide either too much or 
too little anonymity. Transparent cryptocurrencies create the spectre of discriminatory pricing, 
while especially for privacy-enhanced cryptocurrencies the lack of regulation creates an attractive 
environment for fraud and criminal activity from tax evasion to financing of terrorism. 

These problems are easily addressed by combining the register (or ledger) with a central bank 
providing a regulatory framework and monetary policy, including anti-money-laundering and 
know-your-customer enforcement. 


6.2 Electronic Payments 


Day-to-day payments using registers are expensive and inconvenient. Using a register requires 
users to identify themselves to authorize transactions, and the use of register-based banking systems 
tends to be more expensive than the direct exchange of physical cash. However, with the ongoing 
digitalization of daily life where a significant number of transactions is realized over networks, 
some form of electronic payments remain inevitable. 

The current alternative to (centrally banked) electronic cash are a payment systems under 
full control of oligopoly companies such as Google, Apple, Facebook or Visa. The resulting 
oligopolies are anti-competitive. In addition to excessive fees, they sometimes even refuse to 
process payments with certain types of legal businesses, which then are often ruined due to lack 
of alternatives. Combining payment services with companies where the core business model is 
advertising is also particularly damaging for privacy. Finally, the sheer size of these companies 
creates systemic risks, just as their global scale creates challenges for regulation. 

As GNU Taler is free software, even without backing by a central bank, Taler would not suffer 
from these drawbacks arising from the use of proprietary technology. 

Furthermore, Taler-style electronic cash comes with some unique benefits: 


* improved income transparency compared to cash and traditional Chaum-style e-cash, 
* anonymity for payers, 
* avoidance of enticement towards consumer debt — especially compared to credit cards, and 


* support of new business models and Internet security mechanisms which require (anony- 
mous) micro-transactions. 


Central banks are carefully considering what might be the right technology to implement an 
electronic version of their centrally banked currency, and with Taler we hope to address most of 
their concerns. Nevertheless, all electronic payment systems, including Taler even when backed 
by central-bank-issued currencies, come with their own inherent set of risks: 


* increased risk of a bank run: in a banking crisis, as it is easier to withdraw large amounts of 
digital cash quickly — even from remote locations; 


* increased volatility due to foreign holdings that would not be as easily possible with physical 
cash; 


* increased risk of theft and disruption: while physical cash can also be stolen (and likely 
with much less effort), it is difficult to transport in volume [FEF15], the risk is increased 
with computers because attacks scale [Hamı8], and generally many small incidents are 
socially preferable over a tiny number of very large-scale incidents; and 


* unavailability in crisis situations without electricity and Internet connectivity. 


We believe that in the case of Taler, some of the risks mentioned above can be mitigated: 
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* Volatility due to foreign holdings and the resulting increased risk of bank runs can be 
reduced by putting limits on the amount of electronic coins that customers can withdraw. 
Limiting the validity periods of coins is another method that can help disincentivize the use 
of Taler as a value store. 


* The use of open standards and reference implementations enables white-hat security re- 
search around GNU Taler, which together with good operational security procedures and 
the possibility of competing providers should reduce the risks from attacks. 


* GNU Taler can co-exist with physical cash, and might even help revive the use of cash if it 
succeeds in reducing credit card use online thereby eliminating a key reason for people to 
have credit cards. 


Unlike cryptocurrencies, Taler does not prescribe a solution for monetary policy or just 
taxation, as we believe these issues need to be subject to continuous political debate and cannot be 
“solved” by simplistic algorithms. What we offer to society is an open and free (as in free speech) 
system with mechanisms to audit merchants’ income, instead of proprietary systems controlled 
by a few oligopoly companies. 
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